最近做了乙個小專案完整的資料庫設計,想總結一些設計上的所得,希望大家多多指教。
有時乙個專案，普通程式設計師一般不會去接觸資料庫設計，一般都有專業的dba或是老程式設計師去設計，下面是我推測的幾點可能原因：
1：新手對專案了解不深，正好這是老鳥的長處。
2：新手對區域性的關注往往大於整體，很難考慮的特別周全。
3：資料庫設計的好壞在某種程度上直接影響專案的複雜度以及效能。
第一：我們要知道什麼是正規化，為什麼說到資料庫設計總要提到乙個名詞：正規化。正規化：符合某一種級別的關係模式的集合。設計資料庫必須遵循一定的規則,在關聯式資料庫中，這種規則就是正規化。
第二：正規化的分類。關聯式資料庫中的關係必須滿足一定的要求，目前關聯式資料庫有六種正規化：第一正規化、第二正規化、第三正規化、第四正規化、第五正規化和第六正規化。滿足最低要求的是第一正規化，其餘正規化以次類推。這麼多的分類並不一定要求全部滿足，平時我們通常是達到第三正規化就行。
第三：正規化的作用？
1:優點：是將其轉化為一些表的過程，這種方法可以使從資料庫得到的結果更加明確。
2:缺點：可能使資料庫產生重複資料，從而導致建立多餘的表。
3:是在識別資料庫中的資料元素、關係，以及定義所需的表和各表中的專案這些初始工作之後的乙個細化的過程。
4:設計正規化是資料庫設計所需要滿足的規範，滿足這些規範的資料庫是簡潔的、結構明晰的，也不會發生插入、刪除和更新操作異常。反之則給程式設計人員製造麻煩，可能儲存了大量不需要的冗餘資訊。
下面來簡單介紹下前三種正規化：
一：第一正規化。是對關係模式的基本要求，不滿足第一正規化的資料庫就不是關聯式資料庫。 所謂第一範是指資料庫表的每一列都是不可分割的基本資料項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重複的屬性。如果出現重複的 屬性，就可能需要定義乙個新的實體，新的實體由重複的屬性構成，新實體與原實體之間為一對多關係。這個單一屬性由基本型別構成，包括整型、實數、字元型、 邏輯型、日期型等。 例如有一張儲存檔案的表,正確應該是這樣：可以看到這個表包含了好幾個列，如果我們把這些資訊都放在一列裡面那麼就不滿足上面定義的1nf了。
create table regulations (
id
intidentity,
title nvarchar(
200)
null
,fileaddress varchar(
255)
null
,opendate datetime
null
,typeid
intnull
,postdate datetime
null
,constraint pk_regulations primary key (id)
)
二：第二正規化:在第一正規化的基礎上建立起來的。要求資料庫表中的每個例項或行必須可以被惟一地區分。通常需要為表加上乙個列，以儲存各個例項的惟一標識。 這個惟一屬性列被稱為主關鍵字或主鍵、主碼。像上面的regulations的id列就是乙個身份標識列(identity)。
三：第三正規化:要求乙個資料庫表中不包含已在其它表中已包含的非主關鍵字資訊。例如：上面有了乙個檔案表 regulations,如果這個表是儲存的主檔案，它相應的還有n個附件資訊的話，我們就需要建立另外一張附件表來儲存附件。兩表如何聯絡起來呢，我們 可以把主檔案表的主鍵隨同附件資訊做為一條記錄插入到附件表中，這裡插入的主檔案表資訊中只包含了主鍵id，並沒有插入其它資訊，這種關係就滿足了第三範 式要求。
create table attachment (
id
intidentity,
fileid
intnull,//
主檔案主鍵id
address varchar(
255)
null
,title nvarchar(
200)
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 aspnet2008 archive 2009 04 08 1431481.html 最近做了乙個小專案完整的資料庫設計,想總結一些設計上的所得,希望大家多多指教。有時乙個專案，普通程式設計師一般不會去接觸資料庫設計，一般都有專業的dba或是老程式設計師...
專案小結之資料庫設計
最近做了乙個小專案完整的資料庫設計,想總結一些設計上的所得,希望大家多多指教。有時乙個專案，普通程式設計師一般不會去接觸資料庫設計，一般都有專業的dba或是老程式設計師去設計，下面是我推測的幾點可能原因 1 新手對專案了解不深，正好這是老鳥的長處。2 新手對區域性的關注往往大於整體，很難考慮的特別周...
專案小結之資料庫設計
最近做了乙個小專案完整的資料庫設計,想總結一些設計上的所得,希望大家多多指教。有時乙個專案，普通程式設計師一般不會去接觸資料庫設計，一般都有專業的dba或是老程式設計師去設計，下面是我推測的幾點可能原因 1 新手對專案了解不深，正好這是老鳥的長處。2 新手對區域性的關注往往大於整體，很難考慮的特別周...