Cane Cat FisherИногда приходится сталкиваться с такими ситуациями, что описал предметную область сущностями, спроектировал таблицы, и тут выясняется, что буквально одна-две строки (объектов предметной области) немного вылезает за принятые упрощения. Вроде бы и игнорировать это нельзя, но и "всеобщую теорию всего" ради мелочи в схему базы вгонять не хочется.


Для определенности, пример. Описываем схему государственного документооборота племени Мумба-Юмба. Три таблицы: документ, тип документа (закон, постановление, приказ, решение, письмо...), и издатель документа (вождь, совет племени, шаман, палач, казначей).

Все бы замечательно, но выясняется: Закон может издать только Вождь. Все остальные типы документов - кто угодно. Но может выяснится что-то еще подобное.

Требуется:
1. Обеспечить непротиворечивость данных в таблице документов, чтобы не прошел Закон от Шамана.
2. В интерфейсе при редактировании и выборе документа по типу и издателю, при выборе "Закон", пользователю должен быть доступен исключительно Вождь.

Напрашиваются решения:

1. В лоб, декларативно. Поскольку выяснилась зависимость типа документа от издателя, делаем таблицу "Допустимые типы документов от издателей", со ссылками на тип и издателя, а документ будет ссылаться уже на эту таблицу.

Все железно, но очень неудобно: эта таблица практически будет декартовым произведением всех типов и издателей (за исключением Закона-Вождя). При добавлении нового типа или издателя - множить декартово произведение.

А что, так много типов и издателей, что это может вызвать неудобство ?

Cane Cat Fisher
2. Чисто процедурно: вешаем триггер на Документ, разрешающий сохранение Законов только от Вождя, и в формах выбора документа вшиваем код "Если в комбобоксТип выбран ЗаконИд, то комбобоксИздатель := ВождьИд и комбобоксИздатель.Disable".

Недостаток - размазывание декларативного по сути ограничения по коду, с константами данных, вшитыми в код. У меня на это некоторая аллергия.

Интересен опыт: сталкивались ли вы с подобными случаями, и как обходили?

Я в такой ситуации однозначно выбираю решение (1) (декларативное), потому что:

1. Декларативное в общем лучше процедурного (триггер).
2. Если нужно изменить правила, то в случае (1) нужно изменить данные в таблице, а в случае (2) изменить код триггера и перекомпилировать его. (1) может сделать и пользователь, а (2) только программист, поэтому решение (1) дешевле.

miksoftКстати, вариант 1 работает только в случае неуменьшения прав с течением времени.
Например, запретит Вождь Палачу выдавать справки о смерти, а разрешит только наблюдающему за казнью Шаману. А старые-то справки, выданные Палачом, в системе должны остаться.


Можно в таблицу, где хранятся права, добавить еще одну колонку, показывающую, активно ли это право или нет. В этом случае на клиенте можно показывать только список активных в данный момент прав и пользователь может выбирать только из него. (Конечно, это не защитит базу данных от использования старых правил другим путем, например, вследствие изменения данных какой-нибудь автоматизированной процедурой).