數據庫設計經驗談(四)

　　[前言]：一個成功的管理系統，是由：[50% 的業務 + 50% 的軟件] 所組成，而 50% 的成功軟件又有 [25% 的數據庫 + 25% 的程序] 所組成，數據庫設計的好壞是一個關鍵。如果把企業的數據比做生命所必需的血液，那么數據庫的設計就是應用中最重要的一部分。有關數據庫設計的材料汗牛充棟，大學學位課程里也有專門的講述。不過，就如我們反復強調的那樣，再好的老師也比不過經驗的教誨。所以我歸納歷年來所走的彎路及體會，并在網上找了些對數據庫設計頗有造詣的專業人士給大家傳授一些設計數據庫的技巧和經驗。精選了其中的 60 個最佳技巧，并把這些技巧編寫成了本文，為了方便索引其內容劃分為 5 個部分：

　　第一部分介紹了設計數據庫之前12個基本技巧，包括命名規范和明確業務需求等(數據庫設計經驗談(1)  )；第二部分介紹設計數據庫表24個指南性技巧，涵蓋表內字段設計以及應該避免的常見問題等(數據庫設計經驗談 (2) )；第三部分主要介紹選擇鍵和索引，包含10個技巧專門涉及系統生成的主鍵的正確用法，還有何時以及如何索引字段以獲得最佳性能等（數據庫設計經驗談 (3) ）。本次第四部分主要討論保證數據完整性，如何保持數據庫的清晰和健壯，如何把有害數據降低到最小程度。

　　第 4 部分 - 保證數據的完整性

　　用約束而非商務規則強制數據完整性

　　如果你按照商務規則來處理需求，那么你應當檢查商務層次/用戶界面：如果商務規則以后發生變化，那么只需要進行更新即可。假如需求源于維護數據完整性的需要，那么在數據庫層面上需要施加限制條件。如果你在數據層確實采用了約束，你要保證有辦法把更新不能通過約束檢查的原因采用用戶理解的語言通知用戶界面。除非你的字段命名很冗長，否則字段名本身還不夠。

　　只要有可能，請采用數據庫系統實現數據的完整性。這不但包括通過標準化實現的完整性而且還包括數據的功能性。在寫數據的時候還可以增加觸發器來保證數據的正確性。不要依賴于商務層保證數據完整性；它不能保證表之間（外鍵）的完整性所以不能強加于其他完整性規則之上。

　　分布式數據系統

　　對分布式系統而言，在你決定是否在各個站點復制所有數據還是把數據保存在一個地方之前應該估計一下未來 5 年或者 10 年的數據量。當你把數據傳送到其他站點的時候，最好在數據庫字段中設置一些標記。在目的站點收到你的數據之后更新你的標記。為了進行這種數據傳輸，請寫下你自己的批處理或者調度程序以特定時間間隔運行而不要讓用戶在每天的工作后傳輸數據。本地拷貝你的維護數據，比如計算常數和利息率等，設置版本號保證數據在每個站點都完全一致。

　　強制指示完整性(參照完整性)

　　沒有好辦法能在有害數據進入數據庫之后消除它，所以你應該在它進入數據庫之前將其剔除。激活數據庫系統的指示完整性特性。這樣可以保持數據的清潔而能迫使開發人員投入更多的時間處理錯誤條件。

　　關系

　　如果兩個實體之間存在多對一關系，而且還有可能轉化為多對多關系，那么你最好一開始就設置成多對多關系。從現有的多對一關系轉變為多對多關系比一開始就是多對多關系要難得多。

　　采用視圖

　　為了在你的數據庫和你的應用程序代碼之間提供另一層抽象，你可以為你的應用程序建立專門的視圖而不必非要應用程序直接訪問數據表。這樣做還等于在處理數據庫變更時給你提供了更多的自由。

　　給數據保有和恢復制定計劃

　　考慮數據保有策略并包含在設計過程中，預先設計你的數據恢復過程。采用可以發布給用戶/開發人員的數據字典實現方便的數據識別同時保證對數據源文檔化。編寫在線更新來“更新查詢”供以后萬一數據丟失可以重新處理更新。

　　用存儲過程讓系統做重活

　　解決了許多麻煩來產生一個具有高度完整性的數據庫解決方案之后，我決定封裝一些關聯表的功能組，提供一整套常規的存儲過程來訪問各組以便加快速度和簡化客戶程序代碼的開發。數據庫不只是一個存放數據的地方，它也是簡化編碼之地。

　　使用查找

　　控制數據完整性的最佳方式就是限制用戶的選擇。只要有可能都應該提供給用戶一個清晰的價值列表供其選擇。這樣將減少鍵入代碼的錯誤和誤解同時提供數據的一致性。某些公共數據特別適合查找：國家代碼、狀態代碼等。

　　預告:在第五部分將介紹各種小技巧，不包括在以上 4 個部分中的其他技巧，五花八門，有了它們希望你的數據庫開發工作會更輕松一些。

原文轉自：http://www.anti-gravitydesign.com