Быстрая CMS
Обратная связь Карта сайта
Главная Создание сайтов Практика Строим CMS Наивное О проекте Блог

Структура данных CMS, часть II

Теперь немного о хитростях. Базы данных могут обеспечивать достаточно быстрый доступ к многочисленным записям большого объема, используя относительно компактные индексы. Индекс описывает расположение записей в базе с привязкой к идентификатору, содержащемуся в ключевом поле. То есть, в базе данных существуют собственно данные и средства навигации.

Будем строить модель данных точно так же. Множество однотипных файлов (по одному для каждой страницы) с уникальным идентификатором страницы в имени файла – это данные страниц. И один «индексный» файл, содержащий в себе описание всей иерархии сайта.

Для каждого раздела нам нужен описатель, отображающий его свойства и положение в иерархии.

Назовем каждый раздел верхнего уровня иерархии «родителем», а содержащиеся в нем подразделы «потомками». Чтобы сориентироваться, где какой раздел, нам необходимо для каждого раздела иметь уникальный идентификатор (лучше всего порядковый номер) – это будет «имя» раздела. А чтобы знать, чьим потомком является каждый раздел, нужно еще и «отчество» – идентификатор предка. Таким образом в описателе любого раздела содержится ссылка на его предка. Для всех разделов верхнего уровня это поле будет пустым, поскольку предков (вышележащих разделов) у них нет.

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

Будем строить описание на примере структуры сайта... скажем, магазина «Рыболов». Вот с такой иерархией.

Поскольку нам нужно будет сформировать псевдостатические ссылки (вида index.html), кроме номера раздела вводим для него ещё уникальный алиас, который используем как имя файла в URL'е страницы. Еще нам понадобится название раздела в меню – оно может не совпалать с заголовком страницы. И добавим ещё пару полей – статус страницы, в котором будем хранить некоторые признаки и идентификатор ветви – номер раздела верхнего уровня, который является предком всей ветви подразделов.

Вот какой набор данных у нас получился:
Id Предок Алиас Меню Доп. Ветвь
1   / Главная 0 1
2   good Товары 0 2
3   about О нас 0 3
4 good morm Мормышки 0 2
5 good popl Поплавки 0 2
6 good hooks Крючки 0 2
7 about requis Реквизиты 0 3
8 about map Схема проезда 0 3

Выбрав из такого набора данных все идентификаторы разделов с пустым полем предка, мы получаем список разделов для формирования главного меню.

Выбрав все идентификаторы с одинаковым предком, получаем список для внутреннего меню подразделов этого предка.

Последовательно выбирая идентификатор предка для текущего раздела, затем для его предка, для предка его предка... и так далее до верха иерархии, мы получаем маршрут от текущего раздела до корня сайта («хлебные крошки» или «как я сюда дошел» – см. линейку над заголовком этой страницы).

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

Теперь, когда структура индекса ясна, можно точно так же упаковать ее для хранения в файле. Для каждого раздела по одной строке:


1||/|Главная|0|1
2||good|Товары|0|2
3||about|О нас|0|3
4|good|morm|Мормышки|0|2
5|good|popl|Поплавки|0|2
6|good|hooks|Крючки|0|2
7|about|requis|Реквизиты|0|3
8|about|map|Схема проезда|0|3

И так далее...

Считать такую структуру из текстового файла и «разобрать» ее в массив труда не представляет. Строки получились короткими, число их соответствует числу разделов. И этот компактный набор данных содержит полную информацию о структуре сайта. Теперь достаточно упаковать строки и текст для каждого раздела в отдельный текстовый файл, дать ему имя, содержащее идентификатор раздела – и задача доступа к данным решается очень просто. Какой бы раздел сайта не был выбран.

Индексный файл считывается и разворачивается в массив. Алиас раздела извлекается из URL, числовой идентификатор раздела находится по алиасу в массиве, файл данных раздела определяется по идентификатору.

Предвижу вопрос – почему для главной страницы выбран странный алиас «/»? Конечно, можно было бы выбрать алиас index, но тогда мы получили бы бич непродуманных статических сайтов – две разные ссылки на одну и ту же главную страницу:
http://yoursite.ru/ – ссылка на корень домена
http://yoursite.ru/index.html – ссылка на индексный файл в корне

Поисковые системы наверняка учтут ссылки в меню сайта на index.html, а вот ссылки на домен с других сайтов будут вести на корень домена. Для нормального распределения ссылочного веса лучше ликвидировать такое «двуличие». Так что ссылок на страницу index.html у нас попросту не будет.