Используй пока возможно таксономию - она под структурирование и заточена, и модулей под нее куча.
Если уже не хватит возможностей таксономии, то подключай CCK + views - но тут уже вручную больше прийдется писать.
Значит, если создам новую общую cck_text и пропишу туда данные (например списком 1 | дом, 2 | дверь, 3 | окно, выбор будет списком) и подключу к разным типам контента, то оно не будет подключаться к нодам, а будет копировать саму себя в каждую ноду что-ли, или как-то по другому?
Мне кажется однозначного ответа по производительности не получить.
Конечно копироваться будет не в ноду, а будет создаваться ссылка на
окно,дом,окно и прочее, иначе это была бы не БД (точнее, как с ней
работать)
По моему субъективному мнению, нагрузка словара таксономии
существенно замедляет работу. Математику еще не смотрел в глубине,
но думаю связано с тем, что словатрь штука как бы глобальная,
и словать можно назначать не одному а нескольким видам
сожержимого, а ССК+Виды это какието конкретные документы.
Делал такое же тестирование, с помощью модуля devel разницы не заметил, выходило приблизительно одинаково по скорости и запросам, что с таксономией что с ССК
Если интересно, посмотри: http://hturkey.ru сделан полностью без использования таксономии. Модуль таксономии вообще отключен за ненадобностью. Почему без таксономии спросите вы? А потому что CCK и views дает более гибкие возможности для автоматической генерации путей и выборок. Ручной работы получается меньше, и пути атоматом красивые делать можно, с произвольным вложением плюс произвольную сортировку можно делать, плюс при необходимости задавать текст над и под выборкой (правда тут автоматизм несколько теряется, но процедура быстрая и не сложная). В таксономии такого просто так не сделаешь. По производительности, уже писал, что прежде чем перейти на такую систему, провел поверхностное тестирование, из которого сделал вывод что разницы особой нет. Даже с ССК чуть быстрей иногда выходило.
Единственный пока что замеченный минус, то что таким образом нельзя делать подчиненных (древовидных) "терминов".
То есть нельзя сделать такого:
Комментарии
Используй пока возможно таксономию - она под структурирование и заточена, и модулей под нее куча.
Если уже не хватит возможностей таксономии, то подключай CCK + views - но тут уже вручную больше прийдется писать.
Вот смотрите, есть сайтик http://romasky.ru/view/katalog
Так вот там структурирование через таксономию, а там где район, через cck_field.
И там - и там все нормально структурируется.
Вопрос в том, что быстрее работает в данном случае? Какой из этих способов будет меньше посылать запросов к базе данных?
Помогите, пожалуйста, найти ответ на эти вопросы. А то не где про быстродействие на данную тему не нахожу ответа....
Ну допустим терминов таксономии у тебя будет 100 а нод 1000-10000.
Думаю быстрее будет работать с таблицей таксономии т.к. она меньше.
Значит, если создам новую общую cck_text и пропишу туда данные (например списком 1 | дом, 2 | дверь, 3 | окно, выбор будет списком) и подключу к разным типам контента, то оно не будет подключаться к нодам, а будет копировать саму себя в каждую ноду что-ли, или как-то по другому?
Мне кажется однозначного ответа по производительности не получить.
Конечно копироваться будет не в ноду, а будет создаваться ссылка на
окно,дом,окно и прочее, иначе это была бы не БД (точнее, как с ней
работать)
По моему субъективному мнению, нагрузка словара таксономии
существенно замедляет работу. Математику еще не смотрел в глубине,
но думаю связано с тем, что словатрь штука как бы глобальная,
и словать можно назначать не одному а нескольким видам
сожержимого, а ССК+Виды это какието конкретные документы.
Допустим у меня есть 100 терминов и 10.000 нод, node_field (где тоже 100 значений) и 10.000 нод.
Какой вариант будет быстрее?
Я тестировал на views + cck + taxonomy.
Выбирал сортировку сначала по одному термину из таксономии, а потом по одному из cck (node_field).
Получилось одинаковое количество обращений к базе.
Подключайся народ! Тема вроде интересная, очень хочется в ней разобраться!
Делал такое же тестирование, с помощью модуля devel разницы не заметил, выходило приблизительно одинаково по скорости и запросам, что с таксономией что с ССК
Вот поэтому и интересно, как это все будет работать при большом объеме данных!?
Народ! Давайте думать вместе!
Ау!? Профи!? Где Вы все?
Если интересно, посмотри: http://hturkey.ru сделан полностью без использования таксономии. Модуль таксономии вообще отключен за ненадобностью. Почему без таксономии спросите вы? А потому что CCK и views дает более гибкие возможности для автоматической генерации путей и выборок. Ручной работы получается меньше, и пути атоматом красивые делать можно, с произвольным вложением плюс произвольную сортировку можно делать, плюс при необходимости задавать текст над и под выборкой (правда тут автоматизм несколько теряется, но процедура быстрая и не сложная). В таксономии такого просто так не сделаешь. По производительности, уже писал, что прежде чем перейти на такую систему, провел поверхностное тестирование, из которого сделал вывод что разницы особой нет. Даже с ССК чуть быстрей иногда выходило.
Единственный пока что замеченный минус, то что таким образом нельзя делать подчиненных (древовидных) "терминов".
То есть нельзя сделать такого:
Большое спасибо за помощь!
Спасибо за тест.