數據庫設計規範

意味深長與歷久彌新,蘊含於簡約之中,與清晰之中,與高效之中.
真正的堅決遠不只是刪繁就簡,而是紛繁裏簡歷秩序.
—– Jonathan Ive

why(爲什麼要做數據庫設計規範)

1 爲了軟件的擴展性
2 提高開發效率(好的數據庫設計可以減少開發中修改數據庫)
3 提高磁盤利用率
4 提高查詢效率

how(怎麼去規範)

1 數據庫選擇

目前市場上包含兩種數據庫

1.1 SQL數據庫(也就是關係型數據庫)MySQL,Oracle,SQL Server等
    特點以及優點:
    更容易理解:二維結構時非常貼近邏輯世界的一個概念,關係模型相對於網狀,層次等其他模型來說更容易理解
    使用方便:通用的SQL語言是的操作關係型數據庫非常方便
    易於維護:豐富的完整性(實體完整性,參照完整性和用戶定義的完整性)大大
減低了數據冗餘和數據不一致的概率.
    瓶頸及缺點:
    進行高併發讀寫
    海量數據的高效率讀寫
    高擴展性和可用性:在基於web的結構當中,數據庫是最難進行
橫向擴展的,當一個應用系統的用戶量和訪問量與日俱增的時候,
數據庫卻沒有辦法想web Server和app server那樣簡單的
通過添加更多的硬件和服務節點來擴展性能和負載能力.
對於很多需要提供24小時不間斷服務的網站來說,多數據庫系統
進行升級和擴展是非常痛苦的事情,往往需要停機維護和數據遷移.
對於網站來講,有些數據不再需要關係型數據庫的跟多特點:
事務一致性
    關係型數據庫在對事物一致性的維護中有很大的開下
,而現在很多web2.0系統對事物的讀寫一致性都不高
讀寫實時性
    對關係數據庫來說,插入一條數據之後立即查,是
肯定可以讀出這條數據的,大師對於很多web應用來說,並不要
這麼高的實時性,比如發一條消息之後,過幾秒乃至幾十秒之後
纔看到這條動態是完全可以接受的
    複雜SQL,特別是多表關聯查詢
        1.2 NoSQL數據庫(非關係型數據庫)
redis,mangoDB等
        它的優點也就是上述講到的關係型數據庫的缺陷

2 效率,存儲空間的考慮

2.1 針對開發效率

        1. 數據庫涉及字符規範
我們約定：採用26個英文字母（區分大小寫）和0－9這十個自然數，加上下劃線_組成，共63個字符。不能出現其他字符（註釋除外）。
        2. 數據庫對象命名規範
        我們約定，數據庫對象包括表、視圖（查詢）、存儲過程（參數查詢）、函數、約束。對象名字由前綴和實際名字組成，長度不超過30。
        前綴：使用小寫字母
        表 tb
        視圖 vi
        存儲過程 sp
        函數 fn
        實際名字：實際名字儘量描述實體的內容，由單詞或單詞組合，每個單詞的首字母大寫，其他字母小寫，不以數字和_開頭。如
        表 User_In=
        視圖 User_List
        存儲過程 User_Delete
    因此，合法的對象名字類似如下。
            表 tbUser_Info tbMessage_Detail
            視圖 vi_Message_List
            存儲過程 sp

3.數據庫表命名規範

我們約定，表名由前綴和實際名字組成。
前綴：使用小寫字母tb，代表表。實際名字中，一個系統儘量採取同一單詞，多個後面加_來連接區分。

因此，合法的表名類似如下。

TbMember

tbMember_Info

tbForum_Board

tbBlog_Comment1

表

表名如Order/UserAccout

符合以下規範：

(1)統一採用單數形式，反對Orders

(2)首字母大寫，多個單詞的話，單詞首字母大寫，反對order/Useraccout/ORDER

(3)避免中文拼音，反對AgentBaoCi

(4)避免下劃線連接，反對User_Accout（下劃線適用Oracle數據庫）

(5)避免名稱過長，反對WebsiteInfomationModifyRecord

(6)多對多關係表，以Mapping結尾，如UserRoleMapping

(7)避免保留字

4.字段命名規範

我們約定，字段由表的簡稱,實際名字組組成。如果此字段關聯另外的字段，那麼加下劃線_連接關聯表字段的字段名。

因此，合法的字段名類似如下。

UserID_MeID
UserName
UserRegDate

字段

字段名如userID/userName/userType

符合以下規範：

(1)首個字母小寫，多個單詞的話，單詞首字母大寫，反對UserID/Userid

(2)必須有一主鍵，主鍵不直接用ID，而是表名+ID，如userID/orderID

(3)常用的字段name，不直接用name，而是表名+Name，如userName/orderName

(4)常用的字段desc，不直接用desc，而是表名+Desc，如userDesc/orderDesc

(5)大寫字母前必須包含至少兩個小寫的字母，反對uID/oID

(6)避免中文拼音

(7)避免下劃線連接

(8)避免名稱過長

(9)避免保留字

對象

(1)存儲過程以SP_爲前綴

(2)觸發器以TR_爲前綴

(3)函數以FN_爲前綴

(4)主鍵以PK_爲前綴

(5)索引以IX_爲前綴

(6)前綴後的首字母大寫，多個單詞的話，單詞首字母大寫，如SP_CountFee

(7)所有的關鍵字的所有字母必須大寫，如SELECT userID,username FROM User

5.視圖命名規範

我們約定，字段由前綴和實際名字組成，中間用下劃線連接。

前綴：使用小寫字母vi，表示視圖。

因此，合法的視圖名類似如下。

vi_User
vi_UserInfo

6.存儲過程命名規範

我們約定，字段由前綴和實際名字加操作名字組成，中間用下劃線連接。

前綴：使用小寫字母sp，表示存儲過程。

操作名字：Insert|Delelte|Update|Caculate|Confirm

例如：

sp_User_Insert

7.數據庫設計文檔規範

所有數據庫設計要寫成文檔，文檔以模塊化形式表達。大致格式如下：

‘——————————————-

’ 表名： tbUser_Info

’ 作者： Yezi(葉子)

’ 日期： 2004-12-17

’ 版本： 1.0
’ 描述：保存用戶資料

’ 具體內容：

’ UserId int，自動增量用戶代碼
’ UserName char(12) 用戶名字

8.sql語句規範

我們約定，所有sql關鍵詞全部大寫，比如SELECT,UPDATE,FROM,ORDER,BY等。

針對存儲空間

1 表設計原則

(1)規範化的優點是減少了數據冗餘，節約了存儲空間，相應邏輯和物理的I/O次數減少，同時加快了增、刪、改的速度。但是一個完全規範化的設計並不總能生成最優的性能，因爲對數據庫查詢通常需要更多的連接操作，從而影響到查詢的速度，而且範式越高性能就會越差。出於性能和方便管理的考慮，原則上表設計應滿足第三範式。有時爲了提高某些查詢或應用的性能而可以破壞規範規則，即反規範化。
(2)對各類數據表應該有不同的處理方式
        基本數據表：描述業務實體的基本信息。例如，人員基本信息、單位基本信息等。應對:此類表插入後一般不會修改 b
        標準編碼表：描述屬性的列表值。例如，職稱、民族、狀態等。應對:此類表中的字段最好用數字表示(做好註釋)
         業務數據表：記錄業務發生的過程和結果。例如，人員調動登記、變更通知單等。應對:此類表可能會有頻繁的插入,修改
         系統信息表：存放與系統操作、業務控制有關的參數。例如，用戶信息、權限、用戶配置信息等。應對:此類表通常之間有很強的關係,最好用關係表關聯兩者之前要關聯的字段,如果需要頻繁查詢可以在關係表中添加索引.

        臨時處理表：存放業務處理過程中的中間結果。
         其他類型表：存放應用層的日誌、消息記錄等此類數據可以採用非關係數據庫進行存儲
         注意:頻繁訪問的數據可以考慮noSQL數據庫,對於數據量大的數據可以選擇分庫,分表

2 數據類型選擇

（1）使用能正確存儲和表示數據的最小類型(列如日期的存儲可以使用timestamp,MySQL對它的存儲進行了優化)
（2）選擇更簡單的數據類型.例如，比較整數的代價小於比較字符，因爲字符集和排序規則使字符比較更復雜。
（3）儘可能把字段定義爲 NOT NULL。對於字段能否NULL，應該在SQL建表腳本中明確指明，不應使用缺省。
（4）一個表中的字段不要太多，理論上不要超過80個。
（5）數據庫中所有布爾型中數值0表示爲假；數值1表示爲真
（6）當字段定義爲字符串類型時,對於非常短的列或者所有值都接近同一長度,char(固定長度)比varchar(可變長度)的有更高的存儲效率,而且char因爲固定長度不容易產生碎片(如固定長度密碼的存儲)
當然對於比較長的字符串使用可變長度的varchar更節省空間
使用varchar合適的情況:字符串列的最大長度比平均長度大的多;
列的更新更少,所以碎片不是問題;
使用了想UITF-8這樣複雜的字符集,每個字符都是用了不同的字節數據進行存儲
（7）字段儘可能有默認值，字符型的默認值爲一個空字符值串，數字型的默認值爲數值0。

3 鍵設計原則:

(1) 爲關聯字段創建外鍵
(2) 所有的鍵(主鍵,外鍵等)都必須唯一
(3) 儘量避免使用複合鍵
(4) 儘可能使用系統生成(如序列SEQUENCE產生)的主鍵

4 索引設計原則:

(1)如果一列出現表達式或函數,不會使用該列上的索引
(2)要索引外鍵
(3)對於索引選擇性高的列使用B-Tree索引
(4)不要索引大型字段(有很多字符的字段)

外鍵約束

（1）對於關聯兩個表的字段，一般應該分別建立主鍵、外鍵。實際是否建立外鍵，根據對數據完整性的要求決定。

（2）根據需要適當設置父表數據修改時對子表的影響：

    父表中刪除數據：級聯刪除；受限刪除；置空值。

    父表中插入數據：受限插入；遞歸插入。

    父表中更新數據：級聯更新；受限更新；置空值。

SQL語句編寫

1．字符類型數據

SQL中的字符類型數據應該統一使用單引號。特別對純數字的字符串，必須用單引號，否則會導致內部轉換而引起性能問題或索引失效問題。利用TRIM(),LOWER()等函數格式化匹配條件。

2．複雜SQL

對於非常複雜的SQL（特別是有多層嵌套，帶子句或相關子查詢的），應該先考慮是否設計不當引起的。對於一些複雜SQL可以考慮使用程序實現。

3．避免IN子句

使用 IN 或 NOT IN 子句時，特別是當子句中有多個值且表數據較多時，速度會明顯下降。可以採用連接查詢或外連接查詢來提高性能。

4．避免使用SELECT * 語句

如果不必要取出所有數據，不要用 * 來代替，應給出字段列表。

5．避免不必要的排序

不必要的數據排序大大的降低系統性能。

6．INSERT語句

使用INSERT語句一定要給出插入值的字段列表，這樣即使表加了字段也不會影響現有系統的運行。

7．多表連接

做多表操作時，應該給每個表取一個別名，每個表字段都應該標明其所屬哪個表。

8．參數的傳遞

SQL語句的編寫，變量儘量使用“?”綁定變量。
儘量只存儲單一實體類型的數據

其他設計技巧

1．避免使用觸發器

觸發器的功能通常可以用其他方式實現。在調試程序時觸發器可能成爲干擾。假如確實需要採用觸發器，最好集中對它文檔化。

2．保存常用信息

讓一個表專門存放一般數據庫信息非常有用。在這個表裏存放數據庫當前版本、最近檢查/修復、關聯設計文檔的名稱、客戶等信息。這樣可以實現一種簡單機制跟蹤數據庫。

3．編制文檔

對所有的命名規範、限制、數據字典、存儲過程、函數都要編制文檔。採用給表、列、觸發器等加註釋的數據庫工具。對開發、支持和跟蹤修改非常有用。對數據庫文檔化也會大大減少犯錯的機會。