Views или чтение с БД ?

Главные вкладки

Аватар пользователя DravE DravE 16 июня 2010 в 19:51

Я начал работать с друпал относительно недавно, и после прочтения с 10 статей пришел к выводу, что модуль views слишком ресурсоемкий.
А так как сайт который я делаю в данный момент предполагает большое количество пользователей к тому же он уже содержит немало модулей, то от Views я решил отказаться, как мне казалось без него можно обойтись и читать данные напрямую с БД.
Но недавно стала задача реализовать ввод/вывод даты (выхода фильма), а также последующую выборку по этой дате и вывода материала с определенной датой или вывод материалов в диапазоне некоторых дат (но вообщем суть понятна). Для этого я использовал модуль data (cck) но в последствии не обнаружил введенных дат в БД.
(Насколько я понял они там хранятся в какой то специальной форме, чтоб в последствии изменения шаблона даты это не влияло на данные в БД.) Вообщем от модуля data тоже пришлось отказаться. После чего для реализации дат в голову пришла только 1 идея, это создать тестовое поле(cck) и в него вводить даты в формате "20100616"(16.06.2010) теперь впринципи диапазон и даже конкретную дату отловить не проблема. Но вот только как быть с их выводом в теле ноды тут есть 2 варианта, либо создавать еще одно поле для "человеческих"(16 Июн 2010) дат или писать функцию которая преобразует дату к "человеческой" и вызывается при каждом отображении тела ноды. Все бы нечего, но полей с датами в одном материале нужно 4 и если для каждой определить по 2 поля (машинное и человеческой), то это 8 лишних полей.

Подскажите как быть:
Продолжить в том же духе? (8 полей - неудобно зато экономно)
Использовать Views + Data? (Загрузить систему окончательно)
Другие варианты ? (Может кто уже сталкивался)

Комментарии

Аватар пользователя DravE DravE 16 июня 2010 в 20:19

"Ch" wrote:
А где именно искали?

Да впринцыпи везде, где они могли хранится, как я уже писал, нашел только шаблоны вывода с чего сделал вывод
"DravE" wrote:
Насколько я понял они там хранятся в какой то специальной форме, чтоб в последствии изменения шаблона даты это не влияло на данные в БД

И даже если я их найду в "этой форме", то их все равно преобразовывать придется к "человеческим", что тоже морока.

Аватар пользователя vgoodvin vgoodvin 16 июня 2010 в 21:55

"DravE" wrote:
Подскажите как быть:
Продолжить в том же духе? (8 полей - неудобно зато экономно)
Использовать Views + Data? (Загрузить систему окончательно)
Другие варианты ? (Может кто уже сталкивался)

1. Изучить что-то типа Django, хорошо когда есть выбор.
2. Кешировать, кешировать, кешировать..., или собираетесь все вытягивать напрямую из базы?

Аватар пользователя DravE DravE 16 июня 2010 в 22:10

Всем спасибо за помощь.
Ch
Совсем забыл про data();
RxB
А вот про format_date() не знал, спасибо!

Порился я еще раз в таблицах и все таки нашел где хранятся "поля с датами" правда они хранились не в timestamp а просто в виде строки (но изменить это несложно). Теперь вот думаю что делать использовать модуль date ( напряжно то, что постоянно придется переводить из типа timestamp в тип data и наоборот при выборке диапазона) , или все таки простые cck поля и своя функция преобразования. Скорее наверно второе так как меньше нагрузки будет и кол. полей одинаково

Аватар пользователя DravE DravE 16 июня 2010 в 22:14

"vgoodvin" wrote:
или собираетесь все вытягивать напрямую из базы?

Я не говорил что все,я имел ввиду например при поиске по определенному полю (дате), что тут кешировать?

Аватар пользователя DravE DravE 17 июня 2010 в 2:37

"RxB" wrote:
Модуль Date поддерживает как timestamp так и хранение в человеческом формат

да вот в чем и проблема что при человеческом формате как выбрать диапазон дат если они в БД хранятся в виде 2009-09-10T00:00:00, (я конечно не профи в mysql).
А при timestamp
"DravE" wrote:
постоянно придется переводить из типа timestamp в тип data и наоборот при выборке диапазона

Аватар пользователя vgoodvin vgoodvin 16 июня 2010 в 22:51

"DravE" wrote:
Я не говорил что все,я имел ввиду например при поиске по определенному полю (дате), что тут кешировать?

При поиске да. Вьюс будет есть ресурсы. Поэтому он и не годится для этого. Если уж зашла речь об оптимизации, то настраивайте какой-нибудь сфинкс. Так будет быстрее и экономнее всего. Причем если наловчиться, то ручной работы будет гораздо меньше, чем вы проделали, главное один раз разобраться. RxB подскажет вам хороший хостинг с вышеупомянутым поисковиком Smile

Аватар пользователя kyky kyky 17 июня 2010 в 2:32

— пришел к выводу, что модуль views слишком ресурсоемкий
— Вообщем от модуля data тоже пришлось отказатьс
Так и от самого Друпала отказаться недолго.
Views — это такое же чтение из базы, по сути, тот же запрос с обработкой и выводом результата. Views может кешироваться. А раздувать 8 (!!!) лишних полей для ускорения — верх извращения.

Аватар пользователя DravE DravE 17 июня 2010 в 16:10

"vgoodvin" wrote:
При поиске да. Вьюс будет есть ресурсы. Поэтому он и не годится для этого. Если уж зашла речь об оптимизации, то настраивайте какой-нибудь сфинкс

Почитал я пару статей про Sphinx и понял, что без него действительно не обойтись, большое спасибо за подсказку.
"vgoodvin" wrote:
RxB подскажет вам хороший хостинг

Если вы про http://it-patrol.ru то хостинг действительно хороший. Обязательно воспользуюсь как только завершу сайт
"kyky" wrote:
Views — это такое же чтение из базы, по сути, тот же запрос с обработкой и выводом результата. Views может кешироваться. А раздувать 8 (!!!) лишних полей для ускорения — верх извращения.

Ну насколько я понял с прочитанных материалах по Вьюсу, то он помимо чтения из базы делает еще кучу не нужных вещей.
А на счет полей, то я остановился на 4 cck полях (что равносильно 4 полям data) + функции преобразования.