Как сделать возможность бесконечнй вложенности категорий?

Question

[Родион Юрченко]

Добрый день !
Собсно - вопрос в заголовке
Но если подробнее, то
Заказчик заранее не знает, ни сколько у него на сайте может быть категорий, ни скодлько ПОДкатегорий, так же любая ПОДкатегория может содержать еще n-е кол-во подкатегорий...
Как это все реализовать поизящнее...
Можно провести аналогию с файловой системой - в любой папке может быть любое кол-во подпапок и т п
В основном вопрос конечно по архитектуре БД, но и если будут вкладки php кода - то я только рад

Answer 1

[amf1k]

Ну так в базе может просто запоминать id категории у под категории?? ну буду поля ID и Parent_ID

Answer 2

[four4]

Файловая система вообще то не бесконечно вложенная может быть....
Довольно небольшое число вложений каталогов допускается.

Ты объясни заказчику, что можно сделать и бесконечно, но работать будет медленее, чем оптимизированное под конкретное количество категорий. Может, он тут же одумается. И заложит с запасом на будущее, например, 20 уровней

Он о посетителях сайта, кстати, подумал? Как они будут продираться сковь эти все вложенности? Объясни ему - тут же станет более конкретным.

А технически бесконечная вложенность реализуется элементарно:

Хотя это и не лучшая модель для хранения данных в реляционных БД
каждая строчка в таблице БД это отдельная категория.
она содержит ссылку (идентификатор, первичный ключ) категории более высокого уровня.
К сожалению, чтобы добраться до всех этих категорий - придется множество запросов делать к БД, а это зело медленно. Чем глубже вложенность - тем медленнее будет работать.

Можно подумать и оптимизировать, но, имхо, овчинка выделки не стоит.
Проще привести заказчику 2 довода (см. выше) - и он тут же станет очень конкретным и можно более оптимальную структуру БД создать.

Comments

[trevoga_su]

> придется множество запросов делать к БД, а это зело медленно. Чем глубже вложенность - тем медленнее будет работать.

Не придется. Пишем cron-скрипт, который раз в Н минут/часов/дней ходит по дереву и записывает для каждой категории, например, всех её прямых и всех потомков. Тем самым при каждом запросе пользователя в разы сократится кол-во запросов, т.к. искать все подчиненные можно будет одним запросом, а сортировать уже на уровне php.

[four4]

trevoga_su:
Если человек задает такой простой вопрос как наш топикстартрер, то не стоит мучать ему головной мозг сразу еще и кроном.

А "по крону" - если слишком редко, то плохо - информация на новые группы товара, по которым пошла реклама, может еще не обновиться на сайте, я знаю точно, что это важно заказчику, так как буквально недели 3 назад сталкивался с подобной проблемой на своем проекте.

А если слишком часто обновляться "по крону" - то совершенно не нужная нагрузка на сайт.

Answer 3

[Игорь]

Ну так обычная древовидная структура.
Необходимый минимум: id и parent_id. Если категория не имеет родителя, то parent_id делайте либо 0 либо null (выбор будет влиять на запросы с count())
Для ускорения запросов возможно понадобиться еще root_id (самый верхний предок), все зависит от задач
Как делать выборку можно почитать к примеру тут: https://habrahabr.ru/post/193166/ ситуация похожая

Answer 4

[trevoga_su]

phpclub.ru/faq/Tree?v=w5u

Answer 5

[ThunderCat]

Уже писалось и тут и на хабре и еще не помню где-то было обсуждение, в целом народ сошелся на дереве, т.е. поле parentid указывающее на предка, у меня в нем еще и уровень вложенности записан, удобно при построении визуальных деревьев. А выборка рекурсивной функцией. На проекте где было овер 1000 категорий с произвольной вложенностью мы написали скрипт который при добавлении новой категории записывал массив категорий в кеш, после чего все из него и бралось, ибо реально напрягало систему. А так работало весьма шустренько.