1.用約束而不是業務規則來加強數據完整性。
如果您根據業務規則處理需求，那麽您應該檢查業務層次結構/用戶界面:如果業務規則後來發生了變化，您只需要更新它們。
如果需求源於維護數據完整性的需要，那麽就需要在數據庫級別施加限制。
如果您確實在數據層中使用了約束，那麽您應該確保有壹種方法可以用壹種用戶能夠理解為什麽更新不能通過約束檢查的語言來通知用戶界面。除非妳的字段名很長，否則字段名本身是不夠的。—拉蒙特·亞當斯
只要有可能，請使用數據庫系統來實現數據完整性。這不僅包括通過標準化實現的完整性，還包括數據的功能性。還可以在寫數據的時候添加觸發器，保證數據的正確性。不依賴業務層保證數據完整性；它不能保證表(外鍵)之間的完整性，所以不能強加在其他完整性規則上。
—彼得·裏奇
2.分布式數據系統
對於分布式系統，在決定是復制每個站點中的所有數據還是將數據保存在壹個地方之前，您應該估計未來五年或10年的數據量。當妳發送數據到其他站點時，妳最好在數據庫字段中設置壹些標簽。在目標站點收到您的數據後更新您的標簽。對於這種數據傳輸，請寫下您自己的批處理或調度程序，以在特定的時間間隔運行，而不是讓用戶在每天工作後傳輸數據。把妳的維護數據復制到本地，比如計算常數和利率，設置版本號，保證每個站點的數據完全壹致。
—蘇海爾技術共和國
3.完整性的強制性指示
有害數據進入數據庫後沒有很好的方法消除，所以妳應該在它進入數據庫前就消除它。激活數據庫系統指示的完整性特征。這可以保持數據的整潔，並迫使開發人員花費更多的時間來處理錯誤情況。
— kol
4.關系
如果兩個實體之間是多對壹的關系，而且有可能轉化成多對多的關系，那麽妳最好壹開始就設置成多對多的關系。從現有的多對壹關系轉變為多對多關系比從多對多關系開始要困難得多。
— CS數據架構師
采納壹種觀點
為了在數據庫和應用程序代碼之間提供另壹個抽象層，您可以為應用程序創建壹個特殊的視圖，而不需要應用程序直接訪問數據表。這樣做還可以讓您在處理數據庫更改時更加自由。
—蓋伊·豪
6.數據保留和恢復計劃
考慮數據保留策略並將其包含在設計流程中，並提前設計您的數據恢復流程。使用壹個可以發布給用戶/開發者的數據字典，可以實現方便的數據識別，保證數據源的文檔化。編寫“更新查詢”的在線更新，以便在以後數據丟失時可以重新處理更新。
— kol
7.使用存儲過程讓系統做繁重的工作
在解決了許多問題以產生具有高完整性的數據庫解決方案之後，我的團隊決定封裝壹些相關表的功能組，並提供壹組常規存儲過程來訪問每個組，以便加速和簡化客戶程序代碼的開發。在此期間，我們發現3GL編碼器設置了所有可能的錯誤條件，如下所示:
SELECT Cnt = COUNT (*)
來自[& lt；表& gt]
其中[& lt；主鍵列& gt]= & lt；新值& gt
如果Cnt = 0
開始
插入到[& lt；表& gt]
([& lt；主鍵列& gt] )
值(& lt新值& gt)
結束
其他
開始
& lt指示重復錯誤& gt
結束
非3GL編碼器會這樣做:
插入到[& lt；表& gt]
([& lt；主鍵列& gt] )
價值觀念
(& lt新值& gt)
IF @@ERROR = 2627 -主鍵約束的文字錯誤代碼
開始
& lt指示重復錯誤& gt
結束
第二個程序要簡單得多，事實上，它利用了我們賦予數據庫的函數。雖然我個人不喜歡用內嵌文字(2627)。但是這可以很容易地通過壹點預處理來代替。數據庫不僅是存儲數據的地方，也是簡化編碼的地方。
—史密斯
8.使用查找
控制數據完整性的最好方法是限制用戶的選擇。只要有可能，就應該為用戶提供壹個清晰的值列表以供選擇。這將減少鍵入代碼時的錯誤和誤解，並提供數據壹致性。壹些公共數據特別適合搜索:國家代碼、狀態代碼等。