Подскажите как организовать бд под меню

Советую разбить на две таблицы - в одной хранить собственно дерево категорий (тут есть разные подхода - nested sets, materialized path, adjacency list - по этим фразам погуглите, у подходов разные достоинства и недостатки)

А в другой - собственно справочник категорий.

В первой таблице храните просто id нужной категории из справочника и при выборке меню join'ите с таблицей-справочником.

Не нужно БД этим вообще напрягать.

---------- Добавлено 25.02.2018 в 12:29 ----------

Микроскоп не жалко?

Уже не считая того, что это будет медленно работать

---------- Добавлено 25.02.2018 в 12:35 ----------

1. Видимо речь об MySQL? Да, реляционные СУБД хреново работают с иерархией. Впрочем и БД "ключ-значение" тоже с ней хреново работают.

2. Придется реализовывать это 2 раза:

Для хранения

Для выдачи пользователю.

Если сделать один раз, то по причине п. 1 простая примитивная выдача из меню будет нагружать сервер совершенно напрасно.

Для хранения делается одна-единственная таблица

В ней 3 поля:

ID - уникальный идентификатор

ParentID - ссылка на ID родительского пункта меню; очевидно, что у меню на первом уровне здесь пусто.

Name - собственно текст.

Но вот писать запрос для извлечения этого всего из БД - вы задолбаетесь.

Реляционные БД, к коим относится и MySQL, это делают криво-косо. Это их родовая особенность. Не обработки иерархий они предназначены.

Впрочем, если глубина вложенности иерархии всегда одна и то же, то дело легче пойдет. Но я бы не стал.

В описанной таблице с тремя полями ID, ParentID, Name имеет смысл хранить данные только для удобства редактиования.

Отдавать пользователями, посещающим сайт, из этой таблицы категорически нельзя, это жутко нецелесообразно тормозить будет.

Отдавать же пользователям следует строго из другой структуры - из того же Memcached, например.

А memcached не микроскоп? БД-то всяко на сайте будет, вот в ней и хранить.

При хранении с помощью nested sets всё дерево (а также ветка, родительская ветка) выбирается в один запрос с использованием числовых полей в условии - я не особо представляю на каких объемах данных это будет тормозить. Джойн по числовому ключу тоже. Да, вставка там нетривиальна, но сдаётся мне, что она выполняться будет на порядки реже, чем выборка.

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

С иерархическими списками неспециализированные для иерархических данных СУБД работают крайне отвратительно.

Неквалифицированные советчики просто ничего не знают кроме MySQL потому и думают, что весь секрет - похитрее (понепонятнее для программиста, чтобы работать было неудобнее с ними) таблицы наделать - что мол летать будет. Ан, нет.

Лучше человеку сразу понять, что инструменты решения разных задач - разные.

А том у меня есть знакомые "программисты" и с 10-летним опытом, что знают только один ответ на вопрос где хранить

🍿

Допустим.

Но вы-то что насоветовали? специализированную иерархическую БД или велосипед из (наверно самой неоптимальной) структуры в реляционной БД и key-value хранилища?

Как в вашей структуре надо будет хранить подкатегорию, у которой может быть сразу два родителя? А если это будут две разных по сути категории с одинаковым названием?

Не допустим, а так и есть. Иерархия это противная штука по производительности для всех распространенных СУБД (а к распространенным относятся классические реляционные MySQL/Postgres и т.п.; а также NoSQL, буде то документо-ориентированные или key-value). Не так плохо с иерархией только если уровень вложенности фиксированный и заранее известный программисту (разумеется если программист умеет это учитывать).

Иерархическая БД для данной задачи не нужна.

Предлагаемый вариант - это самая оптимальная структура в БД - потому что самая простая, более-менее естественная и понятная для программиста (ну насколько позволяют реляционные особенности СУБД). Повторяю еще раз - для хранения, для редактирования. Но не для выдачи пользователю. Эту структуру удобно редактировать и генерировать из нее кэшированные данные.

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

---------- Добавлено 25.02.2018 в 14:04 ----------

Ровно столько вариантов хранить сколько будет вариантов отображения этого пользователю.

Если на всех страницах сайта меню отображается всегда целиком - достаточно хранить один-единственный вариант с полным меню.

Т.е. в случае переименования какой-то из подкатегорий ТС надо будет руками каждую подкатегорию переименовывать?

Термин "инвалидация кэша" вам о чем нибудь говорит?

И как это сочетается с вашим «Не нужно БД этим вообще напрягать»? Структура хранится в БД. Чистить кэш можно к примеру при любых изменениях таблицы категорий.

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