Как хранить данные в БД? Этот вопрос рано или поздно встает перед любым проектировщиком сайта.

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

Но всегда ли это оптимально? Так ли сильно отличаются наборы хранимой информации для разных видов контента? Давайте рассмотрим, какую информацию хранят в БД "типовые" виды контента сайтов.

Статичная страница.

Это страница, содержащая некоторую полезную для посетителя информацию, которая очень редко (или вообще никогда) не изменяется. Список полей-атрибутов этого вида контента:

• Уникальный идентификатор (id) - куда ж без него?
• Идентификатор родительского элемента сайта (parent_id - мы же строим иерархическую систему)
• Заголовок (title)
• Описание (description)
• Краткое содержание (summary - используется в качестве анонса)
• Собственно текст старницы (content)
• Ключевые слова (keywords)
• Идентификатор автора (user_id)
• Дата создания (created)
• Дата последнего изменения (modified)
• Флаг опубликованности (published)
• Идентификатор логического раздела (category)

Вроде ничего не забыл....

Статья в блоге.

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

Комментарий к статье блога.

В плане хранения информации, отличия от статичной страницы минимальны. Список полей:

• Уникальный идентификатор (id)
• Идентификатор статьи с в блоге, к которой относится данный комментарий (parent_id)
• Заголовок (title)
• Собственно текст (content)
• Идентификатор автора (user_id)
• Дата создания (created)
• Флаг промодерированности (published)

Как видим, поля всё теже, что и для статичной страницы, отличие лишь в количестве.

Пост в форуме.

Полностью совпадает со статической страницей.

Ответ к посту в форуме.

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

Запись в новостной ленте.

Полностью совпадает со статической страницей. Лишь будет иметь одно дополнительное поле:

• Дата, начиная с которой новость уже не актуальна (expiried)

Товар в магазине.

Используются все теже поля, что и для записи в новостях, но с небольшими дополнениями:

• цена единицы товара (price)
• количество товара на складе (number)
• картинка товара, лишь для удобства - никто не запрещает ее вставить в само описание товара (image)

Итог.

Проанализировав описанное выше, можно легко сделать вывод, что при проектировании CMF логично создать всего одну (большую) универсальную таблицу в базе данных для хранения практически любого вида контента. При этом для разработчиков модулей можно упростить многие рутинные операции, такие как, программирование ввода одних и тех же данных в разных модулях (created, modified, title, decsription, keywords и т.д.). Разработчику модуля нужно лишь сообщить системе, какие именно поля будет использовать его модуль и система сама сможет создать все необходимые формы для ввода/редактирования данных, с необходимой валидацией.

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

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

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