ArtReal: На грани иронии

Адрес странички на сайте: http://artreal.pp.ru/theme/nodesign/cms/cms4.html

Шашлык из контента

Блочная структура контента

    Контент, как несложно догадаться, это не монолитный кусок непонятного происхождения, а структурированная порция информации. Если мы возьмем статью для сайта, то в ней можно выделить несколько информационных блоков: автор, название, аннотация, вставки, рисунки... и т.д. На последнем месте (по порядку, а не по важности) стоит "основной текст" статьи.
    Это немаловажное свойство контента, во-первых, позволяет упорядочить и формализовать информацию, а во-вторых, приводит к неопределенности в ключевой точке. Мультивариантность в ключевой точке мы сейчас и рассмотрим.
    Как мы будем хранить контент? Допустим, мы решили хранить статью в файле. Чтобы не выискивать нужные нам блоки по всему файлу, сделаем так: каждый информационный элемент занимает одну строчку... в первой строке будет автор, во второй - название, в третьей - аннотация, а со строки N и до конца файла - основной текст. Структура статьи видна как на ладони. Иерархию статьи на сайте можно задать каталогом (уровнем каталога относительно корня сайта), где лежит эта статья, благо современные Web-серверы нормально поддерживают иерархию каталогов.
    Но, с другой стороны, никто не мешает нам запихнуть всю статью в одну строчку в формате CSV*. Тогда в файле можно хранить несколько статей (сколько строчек - столько и статей). В качестве расширенного варианта - информационные блоки можно разделять не спецсимволами, а тегами**, и содержимое файла форматировать "елочкой".
    Третий способ - запихнуть статью в БД. К примеру, в mysql мы можем завести табличку, в которой для каждого информационного блока будет выделено отдельное поле. В таком случае, одна статья - это одна запись. Шаг за шагом - и мы можем разместить в БД весь контент.

    Понятно, что каким бы методом мы не хранили информацию, главное - это сохранить структуру информации и обеспечить удобную работу с этой структурой. Ну, а так как контент - это не монолитная масса, то никто не требует хранить статью одним куском. Поэтому мы можем проделать фокус: разделить статью на две части. В первой части (header) будет вся информация о статье (автор, название и т.д.), а во второй - основной текст статьи (memo). Свойства контента от такой операции не изменяются.
    Тут-то и начинается самое интересное. Вторую часть, как более объемную и инертную, запишем в файл, а заголовок, как более востребуемую часть - в БД. Размещение заголовков в БД дает возможность делать не только различные выборки только необходимых полей, но и производить над ними различные групповые операции. В итоге, часть статьи находится в БД, а часть - в файле. Но, в рамках единой структуры контента, ничего не изменилось.
    При такой постановке ситуации вопрос "Что лучше, СУБД или файлы?" становится бессмысленным.

---
* - comma-separated values
** - базовая идея XML

(a) Контент: Vadim Artamonov, 1999 - 2019 Anno Domini