Пишу сейчас свою небольшую cms. Всякие мелкие детали решил, права пользователей разобрал. Возник один базовый вопрос (если я с ним разберусь - cms будет полностью готова). Есть разделы, в них есть статьи. И есть навигация (меню) - которая должна ссылаться на эти разделы. Объясните пожалуйста логику построения сайта при этом? Простейшее меню (просто разделы без статей) - сделать очевидно - добавляем в базу записи (ID, URL, Information), а потом считываем в меню (SELECT FROM)... А вот разобраться с иерархической структурой (дерево)? Пока ограничусь двухуровневым...
В таблицу разделов добавлякм поле `parent`. Те записи, у которых парент =НУЛЛ - это разделы верхнего уровня. Если парент не нулл - значит это подраздел и в поле хранится ид раздела. Дальше либо используем готовые решения (наверное есть такие, я пользуюсь своими) либо пишем сами несколько функций (методов): получение списка "детей" (тоесть те разделы, которые либо сами либо через предков ссылаются на нуждный раздел) получение списка предков (по цепочке проходим от нужного раздела до корня получив список идшников) построение иерархического массива (у каждого раздела верхнего уровня в ключе "парент" находится подмассив его потомков) вроде все, с этим функционалом уже можно строить и навигацию (предки) и выбор раздела (иерархический массив) и запрет рекурсивного переноса (дисаблим при выборе для переноса всех детей). Можно делать не читая все строчки в массив. Но тогда получится много мелких запросов к БД. Что лучше - я не знаю. Мне кажется при маленьком размере таблицы разделов лучше в массив (память). А если разделов тысячи и десятки тысяч - я плохо представляю такой ресурс и думаю что там уже не мускул. Надеюсь более опытные поправят меня там где я не прав.
Мой вариант даст бесконечную вложеность. Для именно двухуровнего можно сделать проще: Одна таблица для разделов верхнего уровня и вторая (с полем парент ссылающемся на первую таблицу) для разделов второго уровня. Это в реализации проще, но теряется вложеность разделов и появляется проблема при переносе подраздела в верхний уровень. Что нужно - зависит от задач. чаще всего такого функционала достаточно, но иногда требуется и множественная вложеность (каталоги всякие, и прочие иерархческие списки с неизвестным количеством ветвей).