引言資料庫設計是資訊系統設計的基礎，一個好的資料庫設計在滿足了軟體需求之外，還要易維護、易擴充等等要求。當然，對專家們反覆強調的資料的一致性、冗餘性、訪問效率等問題的解決，很大程度上取決於資料庫設計者的經驗和專業水平。但這不妨礙我們根據過去的經驗，從實用的角度給出資料庫設計所要要考慮的問題並儘可能給出相應的解決方案，從而給資訊系統的資料庫設計者一些有益的啟示。（注：這裡的資料庫設計主要指資料庫中表和檢視的schema設計，不涉足資料庫系統中其他方面的設計）那麼怎樣才算是一個好的資料庫設計呢？以下給出一個一般性的標準。

一、一個好的資料庫設計首先要滿足使用者的需求
所有資訊系統最後都將提交給終端使用者使用，對於這一點，相信大家都已經達成共識。但是準確地把握使用者的需求是很難的，雖然

二、一個好的資料庫設計要便於維護和擴充
為了應對使用者需求的修改和新增，也為了滿足各種不同的軟硬體環境下系統的使用，大部分資訊系統都不得不在其生命期中進行升級和調整。在這些升級、調整中，又有相當部分會涉及到資料庫設計的修改，因此，資料庫設計最好從一開始就能在易維護、可擴充的角度多加斟酌。

1、不要為各種編號欄位的設定固定的意義
而是最好通過對照表來建立這種編號和意義的對照關係。舉例來說，很多設計者習慣給部門資訊給出固定的編號，這種設計有個致命的缺陷：那就是由於這種對照關係既然不體現在資料庫中，就必然要用業務邏輯來進行解釋，這樣一來，一有新的調整就不得不

2、列舉資訊要體現在相應在對照表中
而不是體現在使用該資訊的表中的值欄位，這樣做的好處是當用戶希望用該列舉資訊作為查詢條件的時候，通過參照表的方式可以很容易的建立這些資訊，另外也避免了當多個表格中都含有該列舉資訊有可能引起的不一致。

3、用關聯表建立表和表之間的多對多關係
而不要用一個欄位解析的方式進行，舉例來說，為了描述使用者(UserInfo)和角色(RoleInfo)之間的關聯關係，我們要建立對照表UserInfo_RoleInfo，而不要試圖在使用者表中建立一個較長的欄位，如Roles（用RoleID1;RoleID2...的形式構成）來代替，因為這

三、一個好的資料庫設計要具有“可讀性”
如同程式設計書籍中反覆強調的程式設計師一定要在程式碼的可讀性方面下功夫一樣，考慮到資訊系統將來的升級和維護可能要要由另外一批人來進行，因此資料庫設計必然也要具有可理解性。對此，我們參照提高程式碼可讀性的常用方法，給出一些建議：

1、用設計文件來提高資料庫設計的可讀性
這點基本對應於“可讀性”程式碼裡面的註釋。在一個合格的資料庫設計文件中必須給出資料庫中的每個表、每個欄位、表間的關聯關係以及各種約束的意義以及由來，從而有可能讓開發者根據使用者需求和設計文件就能理解正確資料庫的設計。

2、給表和檢視起一個有意義的名字
這點對應於coding規範中的變數和函式的命名，很顯然，CustomerInfo的名字很容易聯想到該表中含有客戶資訊，而把它命名為Table0001只能讓人感到費解外。另外，如果DBMS提供表和檢視名的大小寫支援，該名稱最好由每個構成單詞（首字母大寫）拼接而成。

3、用字首給出表和檢視內容之外的其他資訊
如給參照表Ref_字首，這樣就可以讓業務邏輯實現人員根據表的名字知道他所要操作的是不是張參照表，從而幫助他更快地理解詳細設計，並有可能及早發現裡面的錯誤。同樣，給所有檢視加上V_字首，就可以讓業務邏輯程式設計者很容易地知道他現在面臨的是一個表還是檢視，從而避免了對檢視進行更新操作這種低階的錯誤。

4、給每一個欄位起一個有意義的名字
如給CustomerInfo表中的電子郵件欄位起名EMail讓人很容易明白它的準確含義，而Field05則讓人不知所云。基於同樣的道理，數據庫設計中也不能給欄位起一個張冠李戴的名字。

5、欄位命名要考慮上下文
舉例來說，在UserInfo表中，用UserName來表示使用者名稱欄位就不如Name來的更加合適。這種情況畫蛇添足的情況在對照表的設計中體現得尤為明顯，如把部門對照表(Ref_Department)中的部門ID欄位命名為DepartmentID，把部門名稱欄位命名為DepartmentName等等。

6、檢視的設計不要牽扯到其他檢視
與程式碼設計中函式呼叫最好不要巢狀過多層次相對應，為了便於資料庫設計的閱讀人能夠很好地理解設計，檢視最好直接建立在表上。

7、同一表中的記錄最好不要相互引用
這種引用關係不僅讓資料庫設計的閱讀人云裡霧裡，也不便於業務邏輯程式碼的編寫。

8、關聯表的命名用關聯的表名中間加下劃線連線構成
如學生(StudentInfo)和課程(CourseInfo)的關聯表起名StudentInfo_CourseInfo。

四、一個好的資料庫設計能夠滿足空間和效率的要求
對於一個資訊系統來說，在實現使用者需求的基礎之上，保證一個較低的空間佔用以及短的響應時間都是理智的客戶所願意看到的。那麼在這一方面，資料庫設計又要做些什麼工作呢？

1、使用varchar而不要使用char欄位
對於不定長資訊如使用者的簡介資訊，varchar的使用可以減少近一半的空間佔用。當然這點不能一概而論，如用相應長度的char儲存定長文字資料就比varchar來的合適。

2、不要使用BLOB欄位存放“大資料”
BLOB欄位誠如其名，本身是為儲存二進位制大資料而出現的，同樣的道理也適用於某些DBMS所引入的TEXT欄位。因為對於一般資訊系統而言，最長的欄位往往是一些描述文字資訊，而DBMS對char/varchar的長度基本能滿足這種需求。因此積極建議設計者對一些貌似很長的文字的最大允許長度進行確認，在此基礎上參照DBMS中的開發手冊來決定是否採用大欄位。

3、不要使用設計器預設的欄位長度
這種做法一方面縱容了設計者對使用者需求的一知半解以及對設計敷衍了事的不良習慣，另外一方面也在資料的儲存上浪費了不少的空間，因為使用預設欄位長度的情況往往發生在欄位上。

4、不要輕易使用unicode文字欄位
DBMS對unicode的支援在幫助產品國際化的同時，也在一定程度上帶來空間上的浪費，尤其是在當要儲存的文字中的基本都是ASCII字元的情況下，這種浪費尤為明顯。因此，建議設計者在選擇unicode的理由，一定是出於國際化的考慮，而不是其他。因為大多數的大字符集和ASCII字元並存情況下所要碰到的問題基本上都已經由DBMS提供商解決。

5、使用預計算表來提高響應速度
跟資料倉庫裡面的某些思路相似，當業務邏輯中需要用倒根據歷史資訊得來的統計資料時，最好由獨立於系統的預計算模組或相應的DW工具定期完成這些統計資料的預計算。

五、一個好的資料庫設計可以簡化業務邏輯的設計
所有的資料庫設計都不是孤立的，它通過相應的業務邏輯實現（三層結構中還有表現層）來形成最終的產品，因此一個好的資料庫設計應該能夠幫助降低業務邏輯的編寫難度，最起碼不要給業務邏輯的設計、編碼帶來額外工作。

1、所有允許為空的欄位必須是基於使用者需求，而不是出於設計上方便的考慮。這樣帶來的好處是讓詳細設計中的某些錯誤和疏漏（如在設計中沒有考慮對非空欄位的內容檢查）在編碼和單元測試階段就被發現，從而避免了進一步擴散，有助於提高軟體的質量。

2、不要業務邏輯程式碼實現唯一性約束
對資料庫表中的某些欄位（或者多個欄位的組合）的唯一性約束應該儘可能地加到資料庫端。因為這種約束工作交給業務邏輯中去實現代價高昂而且不可靠。

3、關聯約束一定要建立在資料庫端
分析出設計中所涉及的主外來鍵引用關係並體現在資料庫設計中。這一條出於兩點考慮：降低業務邏輯的編寫難度和資料關聯性約束的要求。