Создание меню с использованием древовидных структур с родительскими / дочерними отношениями на основе реляционной базы данных очень громоздко. Реляционные базы данных ужасны для древовидных структур. Они требуют, чтобы вы написали много бизнес-логики просто для представления ваших данных в удобочитаемом формате. Обновление меню с дополнительными функциями требует добавления к этому рекурсивному циклу ... оно может стать очень сложным, в зависимости от сложности вашего меню. Не говоря уже о том, что в конечном итоге вы захотите все это кэшировать, потому что цикл становится довольно дорогим в вычислительном отношении при больших нагрузках. Подумайте об этом, если у вас есть 5 пунктов меню верхнего уровня, 2 дочерних элемента и каждый дочерний элемент, имеющий n самих дочерних элементов, вы будете выполнять 16 операторов SQL.
Могу ли я предложить другое решение: JSON . Раньше у меня была такая таблица меню, и теперь я просто сохраняю ее представление в формате JSON в базе данных SQL (хотя даже это можно кэшировать в памяти / файловой системе). Меню JSON гораздо более компактно с точки зрения пространства, логично просто читать и не требует возиться с родительскими и дочерними идентификаторами. Это работает намного лучше с PHP (json_encode / decode), превращающим меню в собственный массив. Как и в случае с Javascript, что важно, например, если вы выполняете ajax-вызовы, чтобы изменить порядок своего меню в приложении. Иерархические древовидные структуры - это то, что хорошо в JSON. Это также избавляет от необходимости отслеживать ваш «порядок меню» (потому что порядок массива задается внутренне)
Пример формата меню следующий:
{
["en": "Home", "fr": "Accueil"],
["en": "Settings", "fr": "Paramètres", "child":
{
["en": "Email", "fr": "Email", "role": "EmailUser"]
}
}
Как вы можете видеть, он действительно предлагает дополнительные функциональные возможности, такие как «роль», привязанная к пункту меню. Добавление такого рода функциональности не требует нового рекурсивного кода или изменений в вашей схеме SQL. Это действительно намного более гибко.
Итак, на самом деле я не отвечаю на вопрос, но, надеюсь, предоставлю какой-то совет / понимание того, что, по моему мнению, является лучшим решением этой проблемы.