Модуль pages и structure

Macik	#1 2013-02-13 13:21
Team Thanked: 181 times	Сейчас в таблице `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

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
Members Thanked: 4 times	Хорошая мысль. изменений тоже, видимо, не много. Это новое поле будет обновляться при всяком обновлении страницы, то есть дополнительных обработок не нужно...

esclkm	#3 2013-02-13 18:59
Team Thanked: 76 times	Like самый медленный. Я против такого. Добавлено 44 секунды спустя: Да у в моих проектах дерево часто меняется:-) littledev.ru - мой маленький зарождающийся блог о котонти. снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты

esclkm

#3 2013-02-13 18:59

Team
Thanked: 76 times

Like самый медленный. Я против такого.

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

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

littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты

Macik	#4 2013-02-14 15:07
Team Thanked: 181 times	#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)

Macik

#4 2013-02-14 15:07

Team
Thanked: 181 times

#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
Team Thanked: 76 times	еще 1 но: а кто права учитывать будет... ведь дело не в длинне строки littledev.ru - мой маленький зарождающийся блог о котонти. снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты

esclkm

#5 2013-02-15 15:35

Team
Thanked: 76 times

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

Macik	#6 2013-02-15 16:44
Team Thanked: 181 times	#37028 esclkm: еще 1 но: а кто права учитывать будет... ведь дело не в длинне строки Т.к. в запросе все равно будут дополнительные условия, никто не мешает вставить исключающее условие. В среднем исключенных разделов будет многократно меньше подключаемых. Да и все равно еще надо делать фильтр по дате страницы, ее статусу и прочим параметрам. https://github.com/macik правильный хостинг — https://goo.gl/fjCa1F

Macik

#6 2013-02-15 16:44

Team
Thanked: 181 times

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

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

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

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

esclkm	#7 2013-02-15 17:30
Team Thanked: 76 times	ну это не оправдание. littledev.ru - мой маленький зарождающийся блог о котонти. снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты

esclkm

#7 2013-02-15 17:30

Team
Thanked: 76 times

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

Macik	#8 2013-02-16 23:03
Team Thanked: 181 times	Да собственно, оправдываться тут нечего... Просто еще давно поднимались вопросы по поводу: а. Скорости работы при большом количестве категорий. б. В принципе, корретной работы движка при больших объемах данных https://github.com/macik правильный хостинг — https://goo.gl/fjCa1F

Macik

#8 2013-02-16 23:03

Team
Thanked: 181 times

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

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

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

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

esclkm	#9 2013-02-17 09:27
Team Thanked: 76 times	но это не корректное решение... путь категории в отличие от кода меняется чаще like работает очень не быстро длинна строки запроса и ее скорость не совсем симметричные понятия делать like а потом not in - както не галлантно... и это не сократит, а наоборот увеличит расходы. Для внутренних проекторв можно сделать join littledev.ru - мой маленький зарождающийся блог о котонти. снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты

esclkm

#9 2013-02-17 09:27

Team
Thanked: 76 times

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

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

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

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

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

Macik	#10 2013-02-19 20:26
Team Thanked: 181 times	#37044 esclkm: Для внутренних проекторв можно сделать join Вот это конструктивно. ладно, будет время, набью тестовыми данными сайт - потестирую… https://github.com/macik правильный хостинг — https://goo.gl/fjCa1F