Простая модель данных

CREATE ALGORITHM=MERGE VIEW `site_pages` AS
  SELECT `id`, `name`, `content` FROM `site_categories` WHERE `bits`&3=0

INSERT INTO `site_categories` (`id`, `name`, `content`, `bits`) VALUES
('pages', 'Страницы', '', 3)

Комментарии: 8

1. Не пойму, как связать категории с объектами.

2. Нужно размещать объекты в отдельных таблицах, используя символьный идентификатор категории при формировании имени соответствующей таблицы объектов. Сейчас в Gency используется такое правило формирования имени таблицы объектов: берется символьный идентификатор категории, в котором все дефисы заменяются на символы подчеркивания, после чего к нему добавляется табличный префикс, например site_ или просто символ подчеркивания.

   Также можно размещать объекты в единой таблице и делить их на группы при помощи представлений. Пример создания таких представлений можно найти в статье Как сделать фильтрацию элементов по уровню иерархии?

   Для обратного связывания можно добавить в таблицы объектов специальное поле, предназначенное для хранения идентификаторов категорий. Смотрите тот же пример по ссылке из предыдущего абзаца, в котором связующим является поле div (поле cat там используется для связывания на более глубоком уровне вложенности).

3. Расширение модели, используемое в G-Drive и G-Front (дополнительные биты поля bits и поле module), можно считать отдельным абстрактным слоем. Это позволяет создавать более детализированные базы данных, сохраняя абстрагированность от конкретного front-end-движка.

4. Насчет поля module (имя может быть другим) полностью согласен. Его наличие может быть обусловлено следующей причиной: категориям с определенным режимом, например 0, требуются разные обработчики и при этом какой-то группе таких категорий требуется общий обработчик. Т.е. это поле необходимо, когда недостаточно имеющихся данных для определения обработчика. К тому же номер режима не предназначен для определения обработчика, хотя и может быть использован для этого с учетом ограниченного количества таких номеров.

   Что касается дополнительных битов поля bits, то об их включении в модель нужно подумать. Да, конечно, сама архитектура неявно предполагает наличие двух типов обработчиков. Но вот про возможность обрабатывать (выполнять) шаблоны вне частных обработчиков или вовсе не использовать частные обработчики этого не скажешь.

5. Помимо типа обработчика и выполнения шаблона вне обработчика расширение также позволяет контролировать наличие GET-параметра p. Причем это хорошо укладывается в модель, т.к. в описании соответствующих флагов говорится о пустых и непустых объектах, а сам параметр является достаточно общим (пагинация, для которой он обычно используется, присутствует всюду). Кстати, от имени «p» можно легко абстрагироваться, так же как и от формы представления параметра (помнится, я писал о возможности указывать в строке параметров только значение параметра, например ?1).

   Также обратите внимание на следующий момент. В «новой схеме» отличительным флагом для двух типов обработчиков является бит 4, а не 5, поэтому в модель можно включить из этих двух только бит 4 (используемое сейчас расширение этому не противоречит) и описать его в модели, как флаг, определяющий тип обработчика.

6. Итак, вводится следующее расширение модели в отношении битов поля mode (bits):

   • 2 – разрешить присутствие GET-параметра, например ?p=1, или в общем строки параметров, например ?1 или ?p=1&order=desc, для пустого объекта;
   • 3 – аналогично предыдущему пункту, но для непустого объекта;
   • 4 – может использоваться для определения типа закрепленного за категорией обработчика (значение 1 указывает на необходимость получения обработчиком какого-либо дескриптора активного соединения с базой данных), но не всегда, например в G-Drive это имеет место только при значении 1 бита 5;
   • 5 – аналогично предыдущему пункту, но для альтернативного обработчика, если такой используется.

   Вводится необязательное поле module, значение которого определяет имя или номер закрепленного за категорией обработчика, если это значение отлично от NULL, 0, пустой строки или строки, состоящей из символа 0.

7. Номер режима можно продублировать или разместить в старших разрядах поля mode (bits). Это позволит более эффективно различать категории с режимами 2 и 3, явно используемые в Gency, и категории с режимами 0 и 1.

8. Ниже показана взаимосвязь режима доступа и допустимого формата пути:

   

   Используемые обозначения:

   • abstract – непустой абстрактный объект;
   • database – непустой объект базы данных;
   • category – непустая категория за исключением режима 0, в котором можно использовать в том числе и пустую категорию (в других режимах тоже можно использовать пустую категорию, но тогда будет невозможен доступ к непустым объектам данной категории).

   Режим 3 можно использовать не только для доступа к пустому объекту базы данных при помощи программного каркаса, но и для запрета пути формата /category, если в базе данных не размещать соответствующий пустой объект.