Область применения: достаточно статические структурированные массивы данных, построенные (хотя не обязательно) на основе справочников.
Вид инструмента: система управления данными (CMS) для web приложений.
Реализация: PHP, MySQL.
С точки зрения конечного пользователя, все возможные варианты технической реализации представляется сложным или простым GUI, в котором он может внести тот или иной набор данных. Какой бы GUI не был бы, он ограничен применяемыми элементами ввода данных (контролами): input, select, file, text etc. Этот набор данных описывает документ (запись) и является набором его свойств. Исходя из допустимых вариантов контролов, свойства могут или иметь числовое значение id другого элемента (справочник), или могут описываться текстом.
Поскольку рассмотрение реализации документно-ориентированной БД ведется с точки зрения CMS, то есть еще несколько дополнительных требований: к части данных должен быть быстрый и простой доступ для выполнения быстрого и простого поиска и выполнения наиболее частых сортировок, кроме того должен быть механизм простого управления свойствами документа и ввода данных.
С теоретизированием покончено, поехали.
Таблица первая и главная — хранение самих объектов (документов, записей).
Хранение документов в БД самое простое — каждому новому документу присваивается id, id родительского элемента, текстовое поле для хранения свойств и некоторое количество доп полей о которых позже.
id Название свойства родитель доп_поля
1 Запись_1 xml_свойтва 0 доп_поля
2 Запись_2 xml_свойтва 0 доп_поля
3 Запись_3 xml_свойтва 2 доп_поля
4 Запись_4 xml_свойтва 2 доп_поля
Хранить свойства можно любым способом: от банальных разделителей; и | до json и xml.
Мной был выбран xml по причине простых механизмов работы с ним на PHP и реализации xPath в MySQL
Будем считать, что каждый документ описывается набором свойств заданным в некотором шаблоне — Контент Шаблоне (КШ).
Следующая таблица — таблица описывающая наборы свойств для документов (КШ). В таблице есть текстовое описание шаблона, и подчиненное ему произвольное количество табов, которым в свою очередь может быть подчинено произвольное количество полей.
Название_КШ
Таб_1
поле_1 Текстовое
поле_2 Список
поле_3 Дата
К каждой записи в главной таблице привязывается какой именно КШ с данными к ней относится.
Естественно, что кроме данных необходимо некоторое представление этих данных для пользователя на сайте (не забываем, что мы стоим CMS).
Следующая таблица — таблица описывающая Дизайн Шаблон (ДШ) представления данных из Контент Шаблона. ДШ может быть построен на основе любого шаблонизатора. Мы используем примитивную смесь PHP и HTML.
Теперь давайте вспомним об ограничениях, которые мы наложили и вернемся к дополнительным полям.
Ну, во-первых, в дополнительные поля попадают id относящихся к записи КШ и ДШ. Кроме того, в КШ можно задавать часть полей для хранения не в xml, а непосредственно в таблице БД (типа link1, link2, link3). Этих полей по несколько штук на допустимые в MySQL типы данных — текст, числа, даты.
В дополнительные поля попадают ключевые слова и описания документов, а также информация о правах доступа различных пользователей.
Какие достоинства такого подхода:
простой и гибкий механизм настройки шаблонов вводя данных для неквалифицированного оператора.
получив запись по id одним запросом из БД достается максимальное количество её свойств.
возможность использовать механизм xPath для работы c XML в MySQL.
Какие есть недостатки:
невозможность нативной сортировки по данным, лежащим в XML при хранении в MySQL
медленная выборка по конструкции LIKE ‘%’
Описан принцип, хотя есть полностью реализованная CMS на которой работает рад достаточно крупных проектов.,
