數據表的設計原則:
()不應針對整個系統進行數據庫設計而應該根據系統架構中的組件劃分針對每個組件所處理的業務進行組件單元的數據庫設計;不同組件間所對應的數據庫表之間的關聯應盡可能減少如果不同組件間的表需要外鍵關聯也盡量不要創建外鍵關聯而只是記錄關聯表的一個主鍵確保組件對應的表之間的獨立性為系統或表結構的重構提供可能性
()采用領域模型驅動的方式和自頂向下的思路進行數據庫設計首先分析系統業務根據職責定義對象對象要符合封裝的特性確保與職責相關的數據項被定義在一個對象之內這些數據項能夠完整描述該職責不會出現職責描述缺失並且一個對象有且只有一項職責如果一個對象要負責兩個或兩個以上的職責應進行分拆
()根據建立的領域模型進行數據庫表的映射此時應參考數據庫設計第二范式一個表中的所有非關鍵字屬性都依賴於整個關鍵字關鍵字可以是一個屬性也可以是多個屬性的集合不論那種方式都應確保關鍵字能夠保證唯一性在確定關鍵字時應保證關鍵字不會參與業務且不會出現更新異常這時最優解決方案為采用一個自增數值型屬性或一個隨機字符串作為表的關鍵字
()由於第一點所述的領域模型驅動的方式設計數據庫表結構領域模型中的每一個對象只有一項職責所以對象中的數據項不存在傳遞依賴所以這種思路的數據庫表結構設計從一開始即滿足第三范式一個表應滿足第二范式且屬性間不存在傳遞依賴
()同樣由於對象職責的單一性以及對象之間的關系反映的是業務邏輯之間的關系所以在領域模型中的對象存在主對象和從對象之分從對象是從N或NN的角度進一步主對象的業務邏輯所以從對象及對象關系映射為的表及表關聯關系不存在刪除和插入異常
()在映射後得出的數據庫表結構中應再根據第四范式進行進一步修改確保不存在多值依賴這時應根據反向工程的思路反饋給領域模型如果表結構中存在多值依賴則證明領域模型中的對象具有至少兩個以上的職責應根據第一條進行設計修正第四范式一個表如果滿足BCNF不應存在多值依賴
()在經過分析後確認所有的表都滿足二三四范式的情況下表和表之間的關聯盡量采用弱關聯以便於對表字段和表結構的調整和重構並且我認為數據庫中的表是用來持久化一個對象實例在特定時間及特定條件下的狀態的只是一個存儲介質所以表和表之間也不應用強關聯來表述業務(數據間的一致性)這一職責應由系統的邏輯層來保證這種方式也確保了系統對於不正確數據(髒數據)的兼容性當然從整個系統的角度來說我們還是要盡最大努力確保系統不會產生髒數據單從另一個角度來說髒數據的產生在一定程度上也是不可避免的我們也要保證系統對這種情況的容錯性這是一個折中的方案
()應針對所有表的主鍵和外鍵建立索引有針對性的(針對一些大數據量和常用檢索方式)建立組合屬性的索引提高檢索效率雖然建立索引會消耗部分系統資源但比較起在檢索時搜索整張表中的數據尤其時表中的數據量較大時所帶來的性能影響以及無索引時的排序操作所帶來的性能影響這種方式仍然是值得提倡的
()盡量少采用存儲過程目前已經有很多技術可以替代存儲過程的功能如對象/關系映射等將數據一致性的保證放在數據庫中無論對於版本控制開發和部署以及數據庫的遷移都會帶來很大的影響但不可否認存儲過程具有性能上的優勢所以當系統可使用的硬件不會得到提升而性能又是非常重要的質量屬性時可經過平衡考慮選用存儲過程
()當處理表間的關聯約束所付出的代價(常常是使用性上的代價)超過了保證不會出現修改刪除更改異常所付出的代價並且數據冗余也不是主要的問題時表設計可以不符合四個范式四個范式確保了不會出現異常但也可能由此導致過於純潔的設計使得表結構難於使用所以在設計時需要進行綜合判斷但首先確保符合四個范式然後再進行精化修正是剛剛進入數據庫設計領域時可以采用的最好辦法
()設計出的表要具有較好的使用性主要體現在查詢時是否需要關聯多張表且還需使用復雜的SQL技巧
()設計出的表要盡可能減少數據冗余確保數據的准確性有效的控制冗余有助於提高數據庫的性能
From:http://tw.wingwit.com/Article/program/SQL/201311/16156.html
