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

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

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

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

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

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

идея такая:

в ключевых объектах существует ряд реквизитов, общих для всех объектов системы это

• Дата создания
• Автор
• Дата последнего изменения
• Последний изменивший
• Признак удаления

Для справочников обычно выделяются такие поля

• код
• название

Для документов список общих полей такой

• дата/время операции
• номер документа
• состояние (отношение к проведению)

Если позволяют возможности БД  я бы рекомендовал использовать общую таблицу типа "Системный объект" или "Базовый объект" в которой дублировать записи о любом объекте системы.

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

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

UPD

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


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

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

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

Детали

Есть 2 таблицы объект (к примеру заказ: DocOrder) и таблица предок (BaseObject).

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

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