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

По теме проектирования баз данных написано множество книг и статей, но все они содержат больше технической информации (описания систем индексации, поиска и связывания таблиц) и предлагают дробить всю информацию на множество таблиц, не забыв склеить все это в тугой узел с помощью связей (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 и т.д.). Разработчику модуля нужно лишь сообщить системе, какие именно поля будет использовать его модуль и система сама сможет создать все необходимые формы для ввода/редактирования данных, с необходимой валидацией.

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

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

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

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

Один мой знакомый как-то изрек прекрасную фразу (правда я не уверен, что именно он является автором сего изречения, скорее всего где-то вычитал), которая звучала так:

- Любая идея, она как ребенок - должна быть сначала выношена и только потом рождена.

Идею написания своей CMS я вынашивал очень давно, несколько лет. За это время было около десятка проб и ошибок. Что-то получалось, что-то напротив. Опыта набрался достаточно и теперь точно знаю чего хочу.

Итак, хотя рабочее название у этого творения "FlatCMS", на самом деле это будет не CMS (Content Management System), а скорее CMF (Content Management Framework), ибо возможности того, что обычно зовется CMS, изначально ограничены и сами эти CMS как-правило узко-специфичны. Кроме того они очень неохотно масштабируются, да и гибкостью особой тоже не отличаются.

Другое дело фреймворки! Здесь полная свобода действий - твори не хочу. Но, конечно, есть и обратная сторона медали. Фреймворк - он по-сути просто библиотека с некой инфраструктурой, т.е. чтобы из нее получить полноценный движок для сайта нужно еще хорошенько попотеть.

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

Итак, старт дан. Точнее работа уже началась примерно месяц назад, но идет очень медленно, т.к. свободного времени в моем распоряжении не так уж и много.

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

ЗЫ
Если есть идеи, которые хотелось бы иметь в движке, но ни в одном их (к сожалению) не реализовали, то делитесь - если мне оно приглянется, я его сделаю .