數據庫設計的幾個建議

本文導讀：數據庫設計是信息系統設計的基礎，一個好的數據庫設計在知足了軟件需求以外，還要易維護、易擴充等等要求，還要考慮到數據的一致性、冗餘性、訪問效率，數據庫設計包括：庫的設計，表的設計，字段的設計，主鍵和外鍵的設計，索引設計，約束設計等等，下面介紹數據庫設計的幾個建議

1、通常好的數據庫設計須要注意如下幾點

 

一、一個好的數據庫設計首先要知足用戶的需求

全部信息系統最後都將提交給最終用戶使用，對於這一點，相信你們都已經達成共識。可是準確地把握用戶的需求是很難的，雖然各方面的專家已經從不一樣方面給出瞭解決方案，可是用戶需求仍然是軟件工程中最不肯定的因素之一。

 

二、一個好的數據庫設計要便於維護和擴充

爲了應對用戶需求的修改和添加，也爲了知足各類不一樣的軟硬件環境下系統的使用，大部分信息系統都不得不在其生命期中進行升級和調整。在這些升級、調整中，又有至關部分會涉及到數據庫設計的修改，所以，數據庫設計最好從一開始就能在易維護、可擴充的角度多加斟酌。

 

（1）、不要爲各類編號字段的設定固定的意義

而是最好經過對照表來創建這種編號和意義的對照關係。舉例來講，不少設計者習慣給部門信息給出固定的編號，這種設計有個致命的缺陷：那就是因爲這種對照關係既然不體如今數據庫中，就必然要用業務邏輯來進行解釋，這樣一來，一有新的調整就不得不更新業務邏輯代碼，也就很是容易不一致的錯誤。

 

（2）、枚舉信息要體如今相應在對照表中
 

而不是體如今使用該信息的表中的值字段，這樣作的好處是當用戶但願用該枚舉信息做爲查詢條件的時候，經過參照表的方式能夠很容易的創建這些信息，另外也避免了當多個表格中都含有該枚舉信息有可能引發的不一致。

 

三、用關聯表創建表和表之間的多對多關係
 

而不要用一個字段解析的方式進行，舉例來講，爲了描述用戶(UserInfo)和角色(RoleInfo)之間的關聯關係，咱們要創建對照表UserInfo_RoleInfo，而不要試圖在用戶表中創建一個較長的字段，如Roles（用RoleID1; RoleID2...的形式構成）來代替，由於這樣一來字段解釋須要在業務代碼相應的解析代碼，二來因爲Roles定長，沒法知足用戶角色的擴充。

 

三、一個好的數據庫設計要具備「可讀性」
 

如同編程書籍中反覆強調的程序員必定要在代碼的可讀性方面下功夫同樣，考慮到信息系統未來的升級和維護可能要要由另一批人來進行，所以數據庫設計必然也要具備可理解性。

 

（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）、關聯約束必定要創建在數據庫端
 

分析出設計中所涉及的主外鍵引用關係並體如今數據庫設計中。這一條出於兩點考慮：下降業務邏輯的編寫難度和數據關聯性約束的要求。

 

 

2、數據庫設計的幾個建議

 

1.使用明確、統一的標明和列名，例如 School, SchoolCourse, CourceID。
2.數據表名使用單數而不是複數，例如 StudentCourse，而不是StudentCourses。
3.數據表名不要使用空格。
4.數據表名不要使用沒必要要的前綴或者後綴，例如使用School，而不是TblSchool，或者SchoolTable等等。

5.數據庫中的密碼要加密，到應用中再解密。 （其實就是散列存儲、單向加密）
6.使用整數做爲ID字段，也許如今沒有這個必要，可是未來須要，例如關聯表，索引等等。
7.使用整數字段作索引，不然會帶來很大的性能問題 。
8.使用 bit 做爲布爾字段，使用整數或者varcha是浪費。同時，這類字段應該以「Is」開頭。
 

9.要通過認證才能訪問數據庫，不要給每個用戶管理員權限。
10.儘可能避免使用「select *」，而使用「select [required_column_list]」以得到更好的性能。

11.假如程序代碼比較複雜，使用ORM框架，例如hibernate，iBatis。ORM框架的性能問題能夠經過詳細的配置去解決。
12.分割不常使用的數據表到不一樣的物理存儲以得到更好的性能。
13.對於關鍵數據庫，使用安全備份系統，例如集羣，同步等等。
14.使用外鍵，非空等限制來保證數據的完整性，不要把全部的東西都扔給程序。
15.缺少數據庫文檔是致命的。你應該爲你的數據庫設計寫文檔，包括觸發器、存儲過程和其餘腳本。
 

16.對於常用的查詢和大型數據表，要使用索引。數據分析工具能夠幫助你決定如何創建索引。17.數據庫服務器和網頁服務器應該放在不一樣的機器上。這回提升安全性，並減輕CPU壓力。18.Image和blob字段不該該定義在經常使用的數據表中，不然會影響性能。19.範式（Normalization）要按照要求使用以提升性能。Normalization作的不夠會致使數據冗餘，而過分Normalization 會致使太多的join和數據表，這兩種狀況都會影響性能。20.多花點時間在數據庫設計上，不然你未來會付出加倍的時間來償還