Forums / National / Russian / Идеи / Модуль pages и structure

Macik
#1 2013-02-13 13:21

Сейчас в таблице `cot_pages` есть поле `page_cat`,  в котором хнаниться код категории, которой принадлежит страница.

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

Очень распространенная задача выбрать все страницы из категории и ее подкатегорий. Сейчас решается вызовом `cot_structure_children` (и.т.п), и последующими запросами вида select * … where page_cat in ('1.1','1.2','1.3','1.4', …). 

Кудап проще было бы просто сделать запрос "… where page_cpath LIKE '1.%'".

Опять же имяя под рукой путь категории этой страницы можно в одну строку получить путь корневой категории или путь родительской: 

$root_path = array_shift( explode( '.', $page_cpath) ); 
$parent_path = substr($page_cpath, 0, strrpos($page_cpath, '.') );

 

 

 

https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F
Eugene
#2 2013-02-13 14:43

Хорошая мысль.

изменений тоже, видимо, не много. Это новое поле будет обновляться при всяком обновлении страницы, то есть дополнительных обработок не нужно...

esclkm
#3 2013-02-13 18:59
Like самый медленный. Я против такого.

Добавлено 44 секунды спустя:

Да у в моих проектах дерево часто меняется:-)
littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
Macik
#4 2013-02-14 15:07
#37019 esclkm:
Like самый медленный. Я против такого.

Добавлено 44 секунды спустя:

Да у в моих проектах дерево часто меняется:-)

Да пожалуй на счет скорости соглашусь. На счет изменений дерева, так. тут нет большой разницы обновлять 1 поле или 2.

А вот, что меня смущает в текущем механизме работы с категориями, так это вся структура категорий с их свойствами грузиться массив structure, который постоянно находится в памяти. Что при значительном количестве категорий может быть проблемой.

 

Добавлено 16 часа спустя:

И все же…

Еще помыслил на счет LIKE. Вот пример - инет-магазин количество категорий несколько сотен (700-800), достаточно разветвленное дерево и нам надо провести поиск в определенном разделе сайта включая все его подразделы (их может быть десятки, а может и сотни).

При испотзовании IN (запросы пишу упрощенно просто для понимания) :

SELECT * from cot_pages where page_cat in ('раздел1','подраздел11','подраздел12','подраздел111','подраздел112','подраздел113','подраздел121',…);

Сталкиваемся с тем, что запрос начинает весить очень много, не говоря о том, что каждая дополнительная категория приводит к почти линейному росту времени на выполнение запроса.

У «медленного» на старте LIKE такой зависимости нет, и уже при достаточно небольшом количестве категорий для поиска, LIKE начнет обгонять указанный выше пример.

SELECT * from cot_pages where page_pathcat LIKE '1.%';

Еще есть вариант (хотя не уверен, что он обгонит LIKE):

SELECT * from cot_pages where substr(page_pathcat,1,2) = '1.';

 

 

https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F
This post was edited by Macik (2013-02-15 07:24, 11 years ago)
esclkm
#5 2013-02-15 15:35

еще 1 но: а кто права учитывать будет... ведь дело не в длинне строки

littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
Macik
#6 2013-02-15 16:44
#37028 esclkm:

еще 1 но: а кто права учитывать будет... ведь дело не в длинне строки

Т.к. в запросе все равно будут дополнительные условия, никто не мешает вставить исключающее условие. В среднем исключенных разделов будет многократно меньше подключаемых.

Да и все равно еще надо делать фильтр по дате страницы, ее статусу и прочим параметрам.

https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F
esclkm
#7 2013-02-15 17:30

ну это не оправдание.

littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
Macik
#8 2013-02-16 23:03

Да собственно, оправдываться тут нечего... Просто еще давно поднимались вопросы по поводу:

а. Скорости работы при большом количестве категорий.

б. В принципе, корретной работы движка при больших объемах данных

https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F
esclkm
#9 2013-02-17 09:27

но это не корректное решение... путь категории в отличие от кода меняется чаще

like работает очень не быстро

длинна строки запроса и ее скорость не совсем симметричные понятия

делать like а потом not in - както не галлантно... и это не сократит, а наоборот увеличит расходы.

Для внутренних проекторв можно сделать join

littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
Macik
#10 2013-02-19 20:26
#37044 esclkm:

Для внутренних проекторв можно сделать join

Вот это конструктивно. 

ладно, будет время, набью тестовыми данными сайт - потестирую…

https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F