| Macik |
|
|---|---|
|
Сейчас в таблице `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) );
https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F |
| Eugene |
|
|---|---|
|
Хорошая мысль. изменений тоже, видимо, не много. Это новое поле будет обновляться при всяком обновлении страницы, то есть дополнительных обработок не нужно... |
| esclkm |
|
|---|---|
|
Like самый медленный. Я против такого.
Добавлено 44 секунды спустя: Да у в моих проектах дерево часто меняется:-)littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты |
| Macik |
|
|---|---|
#37019 esclkm: Да пожалуй на счет скорости соглашусь. На счет изменений дерева, так. тут нет большой разницы обновлять 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 |
|
| Отредактировано: Macik (15.02.2013 07:24, 11 лет назад) |
| esclkm |
|
|---|---|
|
еще 1 но: а кто права учитывать будет... ведь дело не в длинне строки littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты |
| Macik |
|
|---|---|
#37028 esclkm: Т.к. в запросе все равно будут дополнительные условия, никто не мешает вставить исключающее условие. В среднем исключенных разделов будет многократно меньше подключаемых. Да и все равно еще надо делать фильтр по дате страницы, ее статусу и прочим параметрам. https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F |
| esclkm |
|
|---|---|
|
ну это не оправдание. littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты |
| Macik |
|
|---|---|
|
Да собственно, оправдываться тут нечего... Просто еще давно поднимались вопросы по поводу: а. Скорости работы при большом количестве категорий. б. В принципе, корретной работы движка при больших объемах данных https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F |
| esclkm |
|
|---|---|
|
но это не корректное решение... путь категории в отличие от кода меняется чаще like работает очень не быстро длинна строки запроса и ее скорость не совсем симметричные понятия делать like а потом not in - както не галлантно... и это не сократит, а наоборот увеличит расходы. Для внутренних проекторв можно сделать join littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты |
| Macik |
|
|---|---|
#37044 esclkm: Вот это конструктивно. ладно, будет время, набью тестовыми данными сайт - потестирую… https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F |
