最近做了一個小項目完整的資料庫設計,想總結一些設計上的所得,希望大家多多指教。
有時一個項目，普通程式員一般不會去接觸資料庫設計，一般都有專業的DBA或是老程式員去設計，下面是我推測的幾點可能原因：
1：新手對項目了解不深，正好這是老鳥的長處。
2：新手對局部的關注往往大于整體，很難考慮的特别周全。
3：資料庫設計的好壞在某種程度上直接影響項目的複雜度以及性能。
第一：我們要知道什麼是範式，為什麼說到資料庫設計總要提到一個名詞：範式。範式：符合某一種級别的關系模式的集合。設計資料庫必須遵循一定的規則,在關系資料庫中，這種規則就是範式。
第二：範式的分類。關系資料庫中的關系必須滿足一定的要求，目前關系資料庫有六種範式：第一範式、第二範式、第三範式、第四範式、第五範式和第六範式。滿足最低要求的是第一範式，其餘範式以次類推。這麼多的分類并不一定要求全部滿足，平時我們通常是達到第三範式就行。
第三：範式的作用？
1:優點：是将其轉化為一些表的過程，這種方法可以使從資料庫得到的結果更加明确。
2:缺點：可能使資料庫産生重複資料，進而導緻建立多餘的表。
3:是在識别資料庫中的資料元素、關系，以及定義所需的表和各表中的項目這些初始工作之後的一個細化的過程。
4:設計範式是資料庫設計所需要滿足的規範，滿足這些規範的資料庫是簡潔的、結構明晰的，也不會發生插入、删除和更新操作異常。反之則給程式設計人員制造麻煩，可能存儲了大量不需要的備援資訊。
下面來簡單介紹下前三種範式：
一：第一範式。是對關系模式的基本要求，不滿足第一範式的資料庫就不是關系資料庫。 所謂第一範是指資料庫表的每一列都是不可分割的基本資料項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重複的屬性。如果出現重複的 屬性，就可能需要定義一個新的實體，新的實體由重複的屬性構成，新實體與原實體之間為一對多關系。這個單一屬性由基本類型構成，包括整型、實數、字元型、 邏輯型、日期型等。 例如有一張存儲檔案的表,正确應該是這樣：可以看到這個表包含了好幾個列，如果我們把這些資訊都放在一列裡面那麼就不滿足上面定義的1NF了。
create table Regulations (
ID int identity,
Title nvarchar(200) null,
FileAddress varchar(255) null,
OpenDate datetime null,
TypeID int null,
PostDate datetime null,
constraint PK_REGULATIONS primary key (ID)
)
二：第二範式:在第一範式的基礎上建立起來的。要求資料庫表中的每個執行個體或行必須可以被惟一地區分。通常需要為表加上一個列，以存儲各個執行個體的惟一辨別。 這個惟一屬性列被稱為主關鍵字或主鍵、主碼。像上面的Regulations的ID列就是一個身份辨別列(identity)。
三：第三範式:要求一個資料庫表中不包含已在其它表中已包含的非主關鍵字資訊。例如：上面有了一個檔案表 Regulations,如果這個表是存儲的主檔案，它相應的還有n個附件資訊的話，我們就需要建立另外一張附件表來存儲附件。兩表如何聯系起來呢，我們 可以把主檔案表的主鍵随同附件資訊做為一條記錄插入到附件表中，這裡插入的主檔案表資訊中隻包含了主鍵ID，并沒有插入其它資訊，這種關系就滿足了第三範 式要求。
create table Attachment (
FileID int null,//主檔案主鍵ID
Address varchar(255) null,
constraint PK_ATTACHMENT primary key (ID)
最後來總結了我這個項目中的具體應用：
第一：啟用資料字典理念來提高開發效率。什麼是資料字典這裡我不多說，大家不知道的可以網上搜尋下。在一個項目中有時會遇到非常多的選項，就是供表單選擇某些小資料項的内容，請看下面的圖：
每一個子產品在插入記錄時都或多或少有這樣的選項，如果每一張表都建一個對應的選項表的話，維護進來工作量相當大，所有可以把這些小資料量的選項存儲到一張表，資料字典表如下：
下面是資料字典的資料展示圖:
第二：對資料庫表字段資料類型的設定有了進一步認識。
1:SQL有一種特殊的資料類型；Unicode 資料類型,包括 Nchar,Nvarchar 和Ntext 傳統的非 Unicode 資料類型允許使用由特定字元集定義的字元。使用 Unicode 資料類型，列中可以存儲任何由Unicode 标準定義的字元。在 Unicode 标準中，包括了以各種字元集定義的全部字元。使用Unicode資料類型，所占用的空間是使用非 Unicode 資料類型的兩倍。當列的長度變化時，應該使用Nvarchar 字元類型。當列的長度固定不變時，應該使用 Nchar 字元類型。我們在表單驗證時，使用者有時會輸入英文和中文混合文字，為了驗證友善，可以将這種情況時的字段設定成Unicode 。
2:對于非Unicode 資料,盡量選擇相對應的類型,例如手機号碼一般都是數字組成，且長度基本固定，設定成char(15)就行,email設定成varchar(100)就行。
第三：如何靈活利用一對多關系。一對多的關系非常常見，但如果加以靈活應用有時效果更佳。
例如，上面的圖中有一個了解管道的選項，它和對應的主表是一對多的關系，如果這個選項在不同的子產品中出現，我們是否需要為每個主表建立一個一對多關系呢? 我選擇做一個中間關系表。我們可以把所有子產品中包含了了解管道選項的主表與這個中間關系表聯系起來，這樣就隻用維護這一個關系表就行了，節約不少時間。
本文轉自左正部落格園部落格，原文連結：http://www.cnblogs.com/soundcode/archive/2013/03/21/2973370.html，如需轉載請自行聯系原作者