觸發器/用於數據完整性的存儲過程器

我有一個名爲Documents的表格，它存儲文件的文件名，備註等。相關的字段有：觸發器/用於數據完整性的存儲過程器

Document_ID - 自動編號
Document_Type_ID - FK查找表Document_Types
Table_Unique_ID

的Table_Unique_ID涉及到任何其他表中，我們使用了其他ID的知道其中表格由相關Document_Type_ID。

E.g.

Document_Type_ID = 1涉及Projects表，所以一個文檔與記錄的1357一個Table_Unique_ID和Document_Type_ID 1意味着它涉及Project_ID = 1357。
Document_Type_ID = 2涉及Sites表，所以一個文檔記錄用的1357和2 Document_Type_IDTable_Unique_ID裝置1357的

等一個Site_ID。

這允許什麼類型的文檔，我們任何表中的各種記錄保持了極大的靈活性，Projects，Sites，Contacts等而不是創建單獨的表（Project_Documents，Site_Documents等）。

但它已經指出，數據的完整性是很難（甚至不可能）使用傳統的簡單的PK/FK關係強加，因爲這1357可能涉及要麼Projects或Sites。

當前數據完整性由用戶界面檢查處理。

問題是，當插入Document記錄或刪除'其他'記錄（Projects,Contacts等）時，觸發器或存儲過程是否有幫助？

如果是這樣，我真的很感激被指出正確的方向。

來源

2015-02-24 Chris Morris

看似很大的靈活性 - 但從數據完整性的角度來看，這是一個**可怕的**設計。我不會浪費時間在調查觸發器和東西 - **修復設計！** – 2015-02-24 15:09:06

我同意@marc_s 100％。設計看起來很「酷」，但實際上它會變得痛苦而緩慢。 – 2015-02-24 15:11:33

*目前數據完整性是由用戶界面檢查處理* - 這使我的膽量畏縮.....基本上，**數據完整性**在這種情況下不***處理.... – 2015-02-24 15:13:19

-2

您的主要目標是什麼？數據完整性，還是靈活性和乾淨的設計？這些是相互矛盾的利益。如果你絕對必須在沒有觸發器的情況下執行完整性，你將不得不有一個更醜陋的設計。必須始終在數據庫設計中做出妥協。你會得到數據完整性的精英們對這種設計有多糟糕的問題感到不安，但是在一天結束時是否值得更正常化呢？

來源

2015-02-24 15:14:38 Necreaux

在大多數嚴肅的商業應用中，數據完整性比「好」的設計重要得多......畢竟，數據是解決方案的基礎。如果你有一個不錯的設計，但是你的數據質量很糟糕 - 你很快就會倒閉。不要爲像「新潮和新潮」設計這樣的東西犧牲所有重要的**數據完整性 - 這些設計每月都會來來去去 - 數十年來您的數據將圍繞（並對您的業務非常重要）。最好是**狀態良好！** – 2015-02-24 15:46:30

觸發器/用於數據完整性的存儲過程器

回答

相關問題