вторник, 6 января 2015 г.

Шаблон Учетной системы в БД: Наследование в базе

(Внимание! статья находится в процессе написания)

В цикл статей Шаблон Учетной системы:

Тема
наследование в базе

Обычно в учетных системах возникает 2 вида основных объектов

  •   справочник
  •   документ

идея такая:

в ключевых объектах существует ряд реквизитов, общих для всех объектов системы это
  • Дата создания
  • Автор
  • Дата последнего изменения
  • Последний изменивший
  • Признак удаления
Для справочников обычно выделяются такие поля
  • код
  • название
Для документов список общих полей такой
  • дата/время операции
  • номер документа
  • состояние (отношение к проведению)
Если позволяют возможности БД  я бы рекомендовал использовать общую таблицу типа "Системный объект" или "Базовый объект" в которой дублировать записи о любом объекте системы.

Применить такую технику наиболее просто, если вы используете Уникальные идентификаторы в качестве ключевых полей.

Тема использования уникальных идентификаторов применительно к MS SQL раскрыта в статье
MS SQL использование GUID как первичных ключей (Primary key)

UPD

ПРОБЛЕМА ВИРТУАЛЬНОГО НАСЛЕДОВАНИЯ!


Все хорошо звучало в теории.

Когда начал реализовывать систему на практике столкнулся с такой проблемой:

Суть проблемы: СУБД ничего не знает о выдуманном нами наследовании :(

Детали

Есть 2 таблицы объект (к примеру заказ: DocOrder) и таблица предок (BaseObject).
Объект связан с предком связью 1 к 1 (первичный ключ в DocOrder = первичный ключ в BaseObject)
Общие поля объектов находятся в BaseObject. в общих полях в частности есть поле "изменивший пользователь".
И теперь на триггере объекта DocOrder не могу повесить проверку контроля прав. т.к. триггер срабатывает до появления записи в таблице-предке BaseObject с общими полями.

Не нашел пока элегантного способа решения этого вопроса.
А это неудобство сводит на нет преимущества новой модели.

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

Отправить комментарий