Шашлык из контента [4]
[начало]
Желание съесть мёд как раз постоянно и не зависит от наличия оного. Хотя в
такой то мере и служит катализатором для его появления. (MicroCell) |
Контент, как несложно догадаться, это не монолитный кусок непонятного происхождения,
а структурированная порция информации. Если мы возьмем статью для сайта, то
в ней можно выделить несколько информационных блоков: автор, название, аннотация,
вставки, рисунки... и т.д. На последнем месте (по порядку, а не по важности)
стоит "основной текст" статьи.
Это немаловажное свойство контента, во-первых, позволяет упорядочить и формализовать
информацию, а во-вторых, приводит к неопределенности в ключевой точке. Мультивариантность
в ключевой точке мы сейчас и рассмотрим.
Как мы будем хранить контент? Допустим, мы решили хранить статью в файле. Чтобы
не выискивать нужные нам блоки по всему файлу, сделаем так: каждый информационный
элемент занимает одну строчку... в первой строке будет автор, во второй - название,
в третьей - аннотация, а со строки N и до конца файла - основной текст. Структура
статьи видна как на ладони. Иерархию статьи на сайте можно задать каталогом
(уровнем каталога относительно корня сайта), где лежит эта статья, благо современные
Web-серверы нормально поддерживают иерархию каталогов.
Но, с другой стороны, никто не мешает нам запихнуть всю статью
в одну строчку в формате CSV*. Тогда в файле можно
хранить несколько статей (сколько строчек - столько и статей). В качестве расширенного
варианта - информационные блоки можно разделять не спецсимволами, а тегами**,
и содержимое файла форматировать "елочкой".
Третий способ - запихнуть статью в БД. К примеру, в mysql мы можем завести табличку,
в которой для каждого информационного блока будет выделено отдельное поле. В
таком случае, одна статья - это одна запись. Шаг за шагом - и мы можем разместить
в БД весь контент.
Понятно, что каким бы методом мы не хранили информацию, главное - это сохранить
структуру информации и обеспечить удобную работу с этой структурой. Ну, а так
как контент - это не монолитная масса, то никто не требует хранить статью одним
куском. Поэтому мы можем проделать фокус: разделить статью на две части. В первой
части (header) будет вся информация о статье (автор, название и т.д.), а во
второй - основной текст статьи (memo). Свойства контента от такой операции не
изменяются.
Тут-то и начинается самое интересное. Вторую часть, как более объемную и инертную,
запишем в файл, а заголовок, как более востребуемую часть - в БД. Размещение
заголовков в БД дает возможность делать не только различные выборки только необходимых
полей, но и производить над ними различные групповые операции. В итоге, часть
статьи находится в БД, а часть - в файле. Но, в рамках единой структуры контента,
ничего не изменилось.
При такой постановке ситуации вопрос "Что лучше, СУБД или файлы?"
становится бессмысленным.
---
* - comma-separated values
** - базовая идея XML