И вот две составляющие службы самурая - военное дело и фортификация. "Кодекс самурая"

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

---
* - с применением метода многомерного гнездования
** - смешно звучит, но большинство "универсальных" CMS узнает о списке рубрик только при запросе в БД