darkcuba
29.05.2014 - 16:40
Всем доброго дня, столкнулся с такой проблемой: До сегодняшнего дня я выводил категории и подкатегории таким образом.
1. Была таблица категории `categories` ( id,name )
2. А так же таблица подкатегории `subcategories` ( id, name, subcat )
И я мог построить на этом такую иерархию:
1 : Категория
-- 1 : Имя Подкатегории : 1 - Ид категории
-- 2 : Имя Подкатегории : 1 - Ид категории
2 : Категория
-- 3 : Имя Подкатегории : 2 - Ид категории
Ну ит.д . И Все. Ну это было конечно моей ошибкой, так как теперь передо мною задача избавиться от ограниченности в количестве вложений.
Мне необходимо щас сделать вот так:
- Категория
-- Подкатегория
--- И еще одна
---- И так без ограничений.
Я прошу помочь лишь с алгоритмом, заранее благодарю за помощь )
T1grOK
29.05.2014 - 16:44
1) id, name, parent_id - много запросов на чтение, минимум на запись.
Тобишь записываем родительский id для категории, для извлечения необходима рекурсия.
2) Nested Sets - один запрос на чтение, много на запись
И еще есть несколько способов хранения деревьев в БД.
_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
darkcuba
30.05.2014 - 02:01
Цитата (T1grOK @ 29.05.2014 - 12:44) |
1) id, name, parent_id - много запросов на чтение, минимум на запись.
Тобишь записываем родительский id для категории, для извлечения необходима рекурсия.
2) Nested Sets - один запрос на чтение, много на запись
И еще есть несколько способов хранения деревьев в БД. |
Все, благодарю. Выбрал 1, надеюсь адекватное решение.
Цитата (darkcuba @ 29.05.2014 - 22:01) |
Все, благодарю. Выбрал 1, надеюсь адекватное решение |
скорее всего нет. Как правило выводить дерево приходится много чаще чем изменять, значит нужно выбирать ту реализация, которая позволяет это делать легче.
Вот тут можно почитать про различные реализации
http://www.arbinada.com/main/node/25.
sergeiss
30.05.2014 - 09:34
Цитата (T1grOK @ 29.05.2014 - 16:44) |
1) id, name, parent_id - много запросов на чтение, минимум на запись.
Тобишь записываем родительский id для категории, для извлечения необходима рекурсия. |
Позволь дополню твой ответ... Возможно, что в Мускуле и ряде других СУБД и нужно много запросов. Но в Постгре всё делается одним единственным запросом. Пруф-линк:
http://phpforum.su/index.php?showtopic=31806Идея простая: все "рекурсии" делаются в пределах одного запроса, используется специфика Постгре. Подробности - по ссылке.
_____________
*
Хэлп по PHP*
Описалово по JavaScript *
Хэлп и СУБД для PostgreSQL*
Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги. *
"накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
DedMorozzz
30.05.2014 - 10:58
Ухххх.... лучше бы не кидал эту ссылку. 1 запрос
![smile.gif](http://phpforum.su/html/emoticons/smile.gif)
По сабжу kaww всё верно говорит, айди-парент айди, для крайне маленьки вложеностей подходит. Для "неограниченых" вложеностей - тот же нестед сетс будет отличным решением
_____________
Если не говорить пользователям, что Linux это "Сложно и страшно", то им совершенно всё равно, в чём не разбираться
T1grOK
30.05.2014 - 16:36
Цитата (DedMorozzz @ 30.05.2014 - 06:58) |
По сабжу kaww всё верно говорит, айди-парент айди, для крайне маленьки вложеностей подходит. Для "неограниченых" вложеностей - тот же нестед сетс будет отличным решением |
Зависит от специфики задачи. Все таки по первому варианту можно и закешировать, а при изменениях кэш обновлять, если позволяет ситуация.
_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
DedMorozzz
30.05.2014 - 21:52
Цитата (T1grOK @ 30.05.2014 - 15:36) |
Все таки по первому варианту можно и закешировать |
А что кешировать будешь? Если вложеность не ограничена и выборка может провзводится "вверх" от любого парента.
Все возможные варианты?
_____________
Если не говорить пользователям, что Linux это "Сложно и страшно", то им совершенно всё равно, в чём не разбираться
Три слова для гугла - Nested Sets, Adjacency List, Materialized Path
В одном быстро читать, другое быстро писать, третье хорошо и тем и другим если не надо по дереву искать, строить пути и писать в середину. Остальное расскажет гугл.
_____________
"Нужно быть готовым прислушиваться к тем, кто может тебя чему-нибудь научить. Иначе ты никогда не вырастешь."
Откровенно я никому ниразу не нагрубил. А дать подзатыльник зарвавшемуся юнцу, так это и ему на пользу, и мне в удовольствие. ©
AllesKlar
T1grOK
31.05.2014 - 11:12
Цитата (DedMorozzz @ 30.05.2014 - 17:52) |
А что кешировать будешь? Если вложеность не ограничена и выборка может провзводится "вверх" от любого парента. Все возможные варианты? |
Цитата (T1grOK @ 30.05.2014 - 17:52) |
Зависит от специфики задачи. |
Цитата (T1grOK @ 30.05.2014 - 17:52) |
если позволяет ситуация. |
Не читаем, совсем не читаем..
_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
Быстрый ответ:
Powered by dgreen
Здесь расположена полная версия этой страницы.