Лев в пустыне
Не будем забывать, что контент на сайте образует иерархическую
систему. При этом тактико-технические данные статьи (header) могут использоваться
в списках рубрик, в списках "еще по теме", в новостях сайта... и прочих
разных местах. Раздельное хранение котлет и супа (заголовка и основного текста)
может стать залогом эффективности при различной частоте использования разных
полей. Иначе говоря, оптимальным является не однородное хранение данных, а комплексное
(гибридное)*.
Как, где и что хранить в общем случае определяется оценками, учитывающими несколько
факторов (или тестами производительности в условиях случайно детерминируемой
нагрузки). Если не углубляться в эти дебри, то нам предстоит выбор "скорость
развертки страницы против динамичности сайта", в котором требуется нащупать
золотую середину.
Динамичность на физическом плане мы определяем как количество запросов, необходимых
для отображения страницы, при условии, что все данные лежат в БД. На логическом
плане - количеством различных полей/блоков (как правило, визуально различимых).
Физическая и логическая структура контента может не совпадать. Если логическую
структуру мы не можем изменять, то над физической можем издеваться как угодно.
В качестве иллюстрации этого принципа рассмотрим мифический проект с умеренно
разветвленной информационной структурой.
В "типичном" случае получается вот что. Для основного текста статьи
чаще всего применяется операция "вставить в шаблон или сгенерированную
страницу". При необходимости выполняется небольшой парсинг и форматирование.
Поэтому проще всего хранить основной текст в файле, а не забивать им БД. А вот
от заголовка (header) требуется большая функциональность, к примеру, выборка
по дате или автору. Такая функциональность достигается размещением заголовков
в базе данных.
Но, опять же, зачем для формирования страницы каждый раз
ползать в БД? Если сайт обновляется один-два раза в день, а не каждые 10 минут,
то не проще ли заранее сгенерировать те выборки, которые чаще всего используются?
Достаточно перестроить список после обновления сайта и вставить его как статическую
информацию. К таким спискам относятся: новые поступления, список статей в рубрике,
список рубрик**.
Стратегию выбора средств хранения контент-базы мы рассмотрим позже, а пока обратим
внимание на структуру. Поскольку физическую структуру лучше всего выбирать из
соображений эффективности работы CMS, а логическую структуру - из соображений
удобства работы с информацией, то имеет смысл обратиться к виртуализации и абстрактным
уровням. На разных уровнях структура контент-базы может изменяться вместе с
методами работы с этой структурой. CMS может работать со структурой А, администратор
контент-системы - со структурой В на более высоком уровне абстракции. Посетитель
же видит логическую структуру С.
---
* - с применением метода многомерного гнездования
** - смешно звучит, но большинство "универсальных" CMS узнает о списке
рубрик только при запросе в БД
(a) Контент: Vadim Artamonov, 1999 - 2019 Anno Domini