Где хранить менюшки сайта?

Question

[Посторонним В.]

Пишу сайт, у которого есть несколько блоков (вверху и по бокам) со списками ссылок. Когда набрасывал на скорую руку сайт в процедурном интерфейсе - просто прописал параметры этих ссылок в двухмерный массив, по типу:

array (
    array(
         'anchor' => 'About', 
         'url' => '/about.html',
         'title' => 'Information about this project', 
         'nofollow' => false,
         'bold' => true
    ),
 ....
)

Теперь собираюсь писать сайт более-менее по-нормальному, с использованием ООП. БД будет использоваться MySQL.

Вопрос - как правильней хранить данные ссылок для этих менюшек? В голову приходят разные (в т. ч. плохие) варианты:

1. Хранить в PHP-массиве.
2. Хранить массивы для каждого меню в одной ячейке таблицы БД.
3. Сделать в БД таблицу для каждого меню.
4. Сделать в БД общую таблицу для ссылок всех меню и указывать в специальном столбце, к какому меню относится ссылка.
5. Реализовать иерархию таблиц со связями.
6. Использовать XML-файлы.
7. Другой вариант?

Какой вариант будем самым адекватным и наименее ресурсозатратным для данного случая? У проекта планируется посещаемость в >10000 хитов/сутки, меню есть на каждой странице сайта.

Спасибо.

Answer 1

[Дмитрий]

Пункт 4 + nested sets

Comments

[65536]

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

[FanatPHP]

65536: во-первых, смысла не имеет, а во-вторых, чувак путает меню с каталогом.

[Дмитрий]

65536: на небольших - наверняка нет. Если у вас всегда будет строго 2 уровня, то точно нет.
FanatPHP: автор не уточнил, всегда ли будет двухмерный массив. Поэтому и меню может иметь сколь угодно много уровней вложенности.

[FanatPHP]

Дмитрий: так не жалко же. В Меню - это элемент UI. То есть, в нем в принципе не может быть много элементов - а только то количество, которое человек в принципе в состоянии прокликать. То есть максимум пара сотен. А уж вложенность тут не важна, может быть любая.

[65536]

Дмитрий: я нестед сетс не пробовал, потому-что не почувствовал острой необходимости ни разу. я по другому сделал. в подавляющем числе случаев нужно вывести дерево для всей таблицы целиком. я сделал так. одним запросом выбираются все строки из таблицы. желательно ограничить выборку только нужными столбцами чтобы не забивать память. нужные это ид, парент_ид и те, которые будут использованы при рендрежке дерева. на основании выборки строится 2 массива, один называется nodes_by_id, второй subnodes_by_id. в первом хрянятся значения выбранных полей с индексом по ид, во втором списки дочерних записей по ид.

загрузили дерево в эти 2 массива, хотим нарисовать. идем по массиву subnodes_by_id[0] (первый уровень), рисуем пункт nodes_by_id[id], проверяем если есть subnodes_by_id[id] то спускаемся на следующий уровень рекурсии, идем по subnodes_by_id[id] и тд

все это занимает памяти на один запрос по нескольким полям по всей таблице + жалкие миллисекунды на трансформации массивов. в быту этого точно хватает. по-моему такие решения как НС это когда уже совсем километровые деревья, но где это бывает?

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