[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Бесконечные подкатегории
darkcuba
Всем доброго дня, столкнулся с такой проблемой: До сегодняшнего дня я выводил категории и подкатегории таким образом.
1. Была таблица категории `categories` ( id,name )
2. А так же таблица подкатегории `subcategories` ( id, name, subcat )
И я мог построить на этом такую иерархию:
1 : Категория
-- 1 : Имя Подкатегории : 1 - Ид категории
-- 2 : Имя Подкатегории : 1 - Ид категории

2 : Категория
-- 3 : Имя Подкатегории : 2 - Ид категории

Ну ит.д . И Все. Ну это было конечно моей ошибкой, так как теперь передо мною задача избавиться от ограниченности в количестве вложений.
Мне необходимо щас сделать вот так:

- Категория
-- Подкатегория
--- И еще одна
---- И так без ограничений.

Я прошу помочь лишь с алгоритмом, заранее благодарю за помощь )

T1grOK
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
Цитата (T1grOK @ 29.05.2014 - 12:44)
1) id, name, parent_id - много запросов на чтение, минимум на запись.

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

2) Nested Sets - один запрос на чтение, много на запись

И еще есть несколько способов хранения деревьев в БД.

Все, благодарю. Выбрал 1, надеюсь адекватное решение.
kaww
Цитата (darkcuba @ 29.05.2014 - 22:01)
Все, благодарю. Выбрал 1, надеюсь адекватное решение
скорее всего нет. Как правило выводить дерево приходится много чаще чем изменять, значит нужно выбирать ту реализация, которая позволяет это делать легче.
Вот тут можно почитать про различные реализации http://www.arbinada.com/main/node/25.
sergeiss
Цитата (T1grOK @ 29.05.2014 - 16:44)
1) id, name, parent_id - много запросов на чтение, минимум на запись.

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

Позволь дополню твой ответ... Возможно, что в Мускуле и ряде других СУБД и нужно много запросов. Но в Постгре всё делается одним единственным запросом. Пруф-линк: http://phpforum.su/index.php?showtopic=31806

Идея простая: все "рекурсии" делаются в пределах одного запроса, используется специфика Постгре. Подробности - по ссылке.

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

user posted image
DedMorozzz
Цитата (sergeiss @ 30.05.2014 - 08:34)
Но в Постгре всё делается одним единственным запросом. Пруф-линк: http://phpforum.su/index.php?showtopic=31806

Ухххх.... лучше бы не кидал эту ссылку. 1 запрос smile.gif

По сабжу kaww всё верно говорит, айди-парент айди, для крайне маленьки вложеностей подходит. Для "неограниченых" вложеностей - тот же нестед сетс будет отличным решением

_____________
Если не говорить пользователям, что Linux это "Сложно и страшно", то им совершенно всё равно, в чём не разбираться
T1grOK
Цитата (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
Цитата (T1grOK @ 30.05.2014 - 15:36)
Все таки по первому варианту можно и закешировать

А что кешировать будешь? Если вложеность не ограничена и выборка может провзводится "вверх" от любого парента.
Все возможные варианты?

_____________
Если не говорить пользователям, что Linux это "Сложно и страшно", то им совершенно всё равно, в чём не разбираться
vital
Три слова для гугла - Nested Sets, Adjacency List, Materialized Path
В одном быстро читать, другое быстро писать, третье хорошо и тем и другим если не надо по дереву искать, строить пути и писать в середину. Остальное расскажет гугл.

_____________
"Нужно быть готовым прислушиваться к тем, кто может тебя чему-нибудь научить. Иначе ты никогда не вырастешь."

Откровенно я никому ниразу не нагрубил. А дать подзатыльник зарвавшемуся юнцу, так это и ему на пользу, и мне в удовольствие. © AllesKlar
T1grOK
Цитата (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
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.