Триггеры / хранимые процедуры для целостности данных

Question

У меня есть таблица документов, в которой хранятся имена файлов, заметки и т. Д. О документах. Соответствующие поля:

• Document_ID - Автономер
• Document_Type_ID - FK к таблице поиска Document_Types
• Table_Unique_ID

Table_Unique_ID относится к любому из других идентификаторов, используемых в других таблицах, и мы знаем, какая таблица по Document_Type_ID,

Например

• Document_Type_ID = 1 относится к Projects таблица, поэтому запись документа с Table_Unique_ID 1357 и Document_Type_ID из 1 означает, что это относится к Project_ID = 1357,

• Document_Type_ID = 2 относится к Sites таблица, поэтому запись документа с Table_Unique_ID 1357 и Document_Type_ID из 2 означает Site_ID 1357

и так далее.

Это обеспечивает большую гибкость для типов документов, которые мы храним для различных записей в любой таблице, Projects, Sites, Contacts и т. д. вместо создания отдельных таблиц (Project_Documents, Site_Documents так далее.).

НО было отмечено, что целостность данных сложнее (или невозможно) навязать, используя традиционные простые отношения PK/FK, так как 1357 может относиться либо к Projects или же Sites,

В настоящее время целостность данных обрабатывается проверками пользовательского интерфейса.

Вопрос в том, могут ли триггеры или хранимые процедуры помочь при вставке Document записи или при удалении "других" записей (Projects, Contacts так далее.)?

Если это так, я был бы очень признателен, если бы меня указали в правильном направлении.

Answer 1

Какова ваша основная цель? Целостность данных или гибкость и чистый дизайн? Это конфликтующие интересы. Если вам абсолютно необходимо обеспечить целостность без триггеров, вам понадобится более уродливый дизайн. Компромиссы всегда должны быть сделаны в дизайне базы данных. Вы поймете, что элитаристы по целостности данных не понимают, насколько плох этот дизайн, но в конце концов стоит ли больше нормализации?