數據庫設計技巧
數據庫設計技巧
1. 設計數據庫之前（需求分析階段）
1) 理解客戶需求，詢問用戶如何看待未來需求變化。讓客戶解釋其需求，而且隨著開發的繼續，還要經常詢問客戶保證其需求仍然在開發的目的之中。
2) 了解企業業務可以在以后的開發階段節約大量的時間。
3) 重視輸入輸出。
在定義數據庫表和字段需求（輸入）時，首先應檢查現有的或者已經設計出的報表、查詢和視圖（輸出）以決定為了支持這些輸出哪些是必要的表和字段。
舉例：假如客戶需要一個報表按照郵政編碼排序、分段和求和，你要保證其中包括了單獨的郵政編碼字段而不要把郵政編碼糅進地址字段里。
4) 創建數據字典和er 圖表
er 圖表和數據字典可以讓任何了解數據庫的人都明確如何從數據庫中獲得數據。er圖對表明表之間關系很有用，而數據字典則說明了每個字段的用途以及任何可能存在的別名。對sql 表達式的文檔化來說這是完全必要的。
5) 定義標準的對象命名規范
數據庫各種對象的命名必須規范。
2. 表和字段的設計（數據庫邏輯設計）
表設計原則
1) 標準化和規范化
數據的標準化有助于消除數據庫中的數據冗余。標準化有好幾種形式，但third normal form（3nf）通常被認為在性能、擴展性和數據完整性方面達到了最好平衡。簡單來說，遵守3nf 標準的數據庫的表設計原則是：“one fact in one place”即某個表只包括其本身基本的屬性，當不是它們本身所具有的屬性時需進行分解。表之間的關系通過外鍵相連接。它具有以下特點：有一組表專門存放通過鍵連接起來的關聯數據。
舉例：某個存放客戶及其有關定單的3nf 數據庫就可能有兩個表：customer 和order。order 表不包含定單關聯客戶的任何信息，但表內會存放一個鍵值，該鍵指向customer 表里包含該客戶信息的那一行。
事實上，為了效率的緣故，對表不進行標準化有時也是必要的。
2) 數據驅動
采用數據驅動而非硬編碼的方式，許多策略變更和維護都會方便得多，大大增強系統的靈活性和擴展性。
舉例，假如用戶界面要訪問外部數據源（文件、xml 文檔、其他數據庫等），不妨把相應的連接和路徑信息存儲在用戶界面支持表里。還有，如果用戶界面執行工作流之類的任務（發送郵件、打印信箋、修改記錄狀態等），那么產生工作流的數據也可以存放在數據庫里。角色權限管理也可以通過數據驅動來完成。事實上，如果過程是數據驅動的，你就可以把相當大的責任推給用戶，由用戶來維護自己的工作流過程。
3) 考慮各種變化
在設計數據庫的時候考慮到哪些數據字段將來可能會發生變更。
舉例，姓氏就是如此（注意是西方人的姓氏，比如女性結婚后從夫姓等）。所以，在建立系統存儲客戶信息時，在單獨的一個數據表里存儲姓氏字段，而且還附加起始日和終止日等字段，這樣就可以跟蹤這一數據條目的變化。
字段設計原則
4) 每個表中都應該添加的3 個有用的字段
•?drecordcreationdate，在vb 下默認是now()，而在sql server 下默認為getdate()
•?srecordcreator，在sql server 下默認為not null default user
•?nrecordversion，記錄的版本標記；有助于準確說明記錄中出現null 數據或者丟失數據的原因
5) 對地址和電話采用多個字段
描述街道地址就短短一行記錄是不夠的。address_line1、address_line2 和address_line3 可以提供更大的靈活性。還有，電話號碼和郵件地址最好擁有自己的數據表，其間具有自身的類型和標記類別。
6) 使用角色實體定義屬于某類別的列
在需要對屬于特定類別或者具有特定角色的事物做定義時，可以用角色實體來創建特定的時間關聯關系，從而可以實現自我文檔化。
舉例：用person 實體和person_type 實體來描述人員。比方說，當john smith, engineer 提升為john smith, director 乃至最后爬到john smith, cio 的高位，而所有你要做的不過是改變兩個表person 和person_type 之間關系的鍵值，同時增加一個日期/時間字段來知道變化是何時發生的。這樣，你的person_type 表就包含了所有person 的可能類型，比如associate、engineer、director、cio 或者ceo 等。還有個替代辦法就是改變person 記錄來反映新頭銜的變化，不過這樣一來在時間上無法跟蹤個人所處位置的具體時間。
7) 選擇數字類型和文本類型盡量充足
在sql 中使用smallint 和tinyint 類型要特別小心。比如，假如想看看月銷售總額，總額字段類型是smallint，那么，如果總額超過了$32,767 就不能進行計算操作了。
而id 類型的文本字段，比如客戶id 或定單號等等都應該設置得比一般想象更大。假設客戶id 為10 位數長。那你應該把數據庫表字段的長度設為12 或者13 個字符長。但這額外占據的空間卻無需將來重構整個數據庫就可以實現數據庫規模的增長了。
8) 增加刪除標記字段
在表中包含一個“刪除標記”字段，這樣就可以把行標記為刪除。在關系數據庫里不要單獨刪除某一行；最好采用清除數據程序而且要仔細維護索引整體性。
3. 選擇鍵和索引（數據庫邏輯設計）
鍵選擇原則：
1) 鍵設計4 原則
•?為關聯字段創建外鍵。
•?所有的鍵都必須唯一。
•?避免使用復合鍵。
•?外鍵總是關聯唯一的鍵字段。
2) 使用系統生成的主鍵
設計數據庫的時候采用系統生成的鍵作為主鍵，那么實際控制了數據庫的索引完整性。這樣，數據庫和非人工機制就有效地控制了對存儲數據中每一行的訪問。采用系統生成鍵作為主鍵還有一個優點：當擁有一致的鍵結構時，找到邏輯缺陷很容易。
3) 不要用用戶的鍵(不讓主鍵具有可更新性)
在確定采用什么字段作為表的鍵的時候，可一定要小心用戶將要編輯的字段。通常的情況下不要選擇用戶可編輯的字段作為鍵。
4) 可選鍵有時可做主鍵
把可選鍵進一步用做主鍵，可以擁有建立強大索引的能力。
索引使用原則：
索引是從數據庫中獲取數據的最高效方式之一。95%的數據庫性能問題都可以采用索引技術得到解決。
1) 邏輯主鍵使用唯一的成組索引，對系統鍵（作為存儲過程）采用唯一的非成組索引，對任何外鍵列采用非成組索引。考慮數據庫的空間有多大，表如何進行訪問，還有這些訪問是否主要用作讀寫。
2) 大多數數據庫都索引自動創建的主鍵字段，但是可別忘了索引外鍵，它們也是經常使用的鍵，比如運行查詢顯示主表和所有關聯表的某條記錄就用得上。
3) 不要索引memo/note 字段，不要索引大型字段（有很多字符），這樣作會讓索引占用太多的存儲空間。
4) 不要索引常用的小型表
不要為小型數據表設置任何鍵，假如它們經常有插入和刪除操作就更別這樣作了。對這些插入和刪除操作的索引維護可能比掃描表空間消耗更多的時間。
這就是全部的數據庫設計技巧，希望大家知道這些技巧之后，能靈活運用數據庫，設計出更完善的數據庫系統。
【編輯推薦】
