MYSQL資料庫命名規則及設計規範

MYSQL資料庫命名規則及設計規範

原文作者： Aeolus (傻鱼)
正體譯者： Fntsrlike (月湖)


 

1. 設計原則

(1) 標準化和規範化 

資料的標準化有助於消除資料庫中的資料冗餘。
標準化有好幾種形式，但Third Normal Form（3NF）
通常被認為在性能、擴展性和資料完整性方面達到了最好平衡。
簡單來說，遵守3NF標準的資料庫的資料表設計原則是：“One Fact in One Place”
即某個資料表只包括其本身基本的屬性，當不是它們本身所具有的屬性時需進行分解。
資料表之間的關係通過外鍵相連接。
有一組資料表專門存放通過鍵連接起來的關聯資料。

舉例：
某個存放客戶及其有關定單的3NF資料庫就可能有兩個資料表：Customer和Order。
Order資料表不包含定單關聯客戶的任何信息，但資料表內會存放一個鍵值，
該鍵指向Customer資料表裡包含該客戶信息的那一行。

事實上，為了效率的緣故，對資料表不進行標準化有時也是必要的。

(2) 資料驅動 (Data-Driven)

採用資料驅動而非硬編碼的方式，
許多策略變更和維護都會方便得多，大大增強系統的靈活性和擴展性。
舉例，假如使用者界面要訪問外部資料源（文件、XML文件、其他資料庫等），
不妨把相應的連接和路徑信息存儲在使用者界面支持資料表裡。

還有，如果使用者界面執行工作流之類的任務（發送郵件、列印信箋、修改記錄狀態等），
那麼產生工作流的資料也可以存放在資料庫裡。
角色權限管理也可以通過資料驅動來完成。

事實上，如果過程是資料驅動的，
你就可以把相當大的責任推給使用者，由使用者來維護自己的工作流過程。

(3) 考慮各種變化

在設計資料庫的時候考慮到哪些資料欄位將來可能會發生變更。
舉例，姓氏就是如此（注意是西方人的姓氏，比如女性結婚後從夫姓等）。
所以，在建立系統存儲客戶信息時，在單獨的一個資料表裡存儲姓氏欄位，
而且還附加起始日和終止日等欄位，這樣就可以跟踪這一資料條目的變化。

2. 資料庫涉及字元規範

採用26個英文字母(區分大小寫)和0-9這十個自然數，加上底線'_'組成，
共63個字元，不能出現其他字元(註解除外)。

注意事項：
(1)
以上命名都不得超過30個字元的系統限制。
變數名稱的長度限制為29(不包括標識字元@)。

(2)
資料對象、變數的命名都採用英文字元，
禁止使用中文命名。絕對不要在命名對象的字元之間留空格。

(3)
小心保留字，要保證你的欄位名沒有和保留字、資料庫系統或者常用訪問方法衝突。

(4)
保持欄位名和類型的一致性，
在命名欄位並為其指定資料類型的時候一定要保證一致性。
假如資料類型在一個資料表裡是INT，那在另一個資料表裡可就別變成CHAR型了。


 

3. 資料庫命名規範

資料庫，資料表一律使用前綴

正式資料庫名使用小寫英文以及下劃線組成，盡量說明是那個應用或者係統在使用的。
比如：
web_19floor_net
web_car

備份資料庫名使用正式資料庫名加上備份時間組成，如：
web_19floor_net_20070403
web_car_20070403

4. 資料表命名規範

資料表名使用小寫英文以及下劃線組成，
盡量說明是那個應用或者係統在使用的。

相關應用的資料表使用同一前綴，
如論壇的資料表使用cdb_前綴，博客的資料表使用supe _前綴，
前綴名稱一般不超過5字
比如：
web_user
web_group
supe_userspace

備份資料表名使用正式資料表名加上備份時間組成，如：
web_user_20070403
web_group_20070403
supe_userspace_20070403


 

5. 欄位命名規範

欄位名稱使用單詞組合完成，
首字母小寫，後面單詞的首字母大寫，最好是帶錶名前綴。
如web_user資料表的欄位： 
userId
userName
userPassword

資料表與資料表之間的相關聯欄位要用統一名稱，
如web_user資料表裡面的userId和web_group資料表裡面的userId相對應


6. 欄位類型規範
規則：
盡量用較少的儲存空間來儲存數一個欄位的資料。
比如能用INT的就不用CHAR或者VARCHAR
能用TINYINT的就不用INT
能用VARCHAR (20)的就不用VARCHAR (255)

時間戳欄位盡量用INT型，如
created：
表示從'1970-01-01 08:00:00'開始的INT秒數，
採用英文單詞的過去式；

gmtCreated ：
表示DATETIME類型的時間，
即形如'1980-01-01 00:00:00'的時間串，Java中對應的類型為TIMESTAMP


 

7. 資料庫設計文件規範

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

 
'-------------------------------------------
'表名： web_user
'作者： Aeolus(傻魚)
'日期： 2007-04-11
'版本： 1.0
'描述：保存使用者資料
'具體內容：
' UserID INT，自動增量使用者代碼
' UserName CHAR(12 )使用者名字
' ......
'-------------------------------------------

8. 索引使用原則：

(1)
邏輯主鍵使用唯一的成組索引，
對系統鍵 (作為儲存過程) 採用唯一的非成組索引，
對任何外鍵列採用非成組索引。
考慮資料庫的空間有多大，資料表如何進行訪問，
還有這些訪問是否主要用作讀寫。

(2)
大多數資料庫都索引自動創建的主鍵欄位，
但是可別忘了索引外鍵，它們也是經常使用的鍵，
比如運行查詢顯示主資料表和所有關聯資料表的某條記錄就用得上。

(3)
不要索引blob/text等欄位，不要索引大型欄位(有很多字元)，
這樣作會讓索引佔用太多的儲存空間。

(4)
不要索引常用的小型資料表
不要為小型資料表設置任何鍵，假如它們經常有插入和刪除操作就更別這樣作了。
對這些插入和刪除操作的索引維護可能比掃描資料表空間消耗更多的時間。  

9. SQL語句規範

所有SQL關鍵字全部大寫，比如SELECT、UPDATE、FROM、ORDER、BY等，
所有的資料表名和資料庫名都要用``包含
如：
SELECT COUNT(*) FROM `cdb_members` WHERE `userName` = 'aeolus';

10. 其他設計技巧

(1) 避免使用觸發器
觸發器的功能通常可以用其他方式實現。在調試程序時觸發器可能成為乾擾。
假如你確實需要採用觸發器，你最好集中對它文件化。

(2) 使用常用英語(或者其他任何語言)而不要使用編碼或者拼音首字母縮寫
在創建下拉菜單、列表、報表時最好按照英語名排序。
假如需要編碼或者拼音首字母縮寫，可以在旁邊附上使用者知道的英語。

(3) 保存常用信息
讓一個資料表專門存放一般資料庫信息非常有用。

在這個資料表裡存放：
資料庫當前版本、最近檢查/修復(對Access )、關聯設計文件的名稱、客戶等信息。

這樣可以實現一種簡單機制跟踪資料庫，
當客戶抱怨他們的資料庫沒有達到希望的要求而與你聯繫時，
這樣做對非客戶機/服務器環境特別有用。

(4) 包含版本機制
在資料庫中引入版本控制機制來確定使用中的資料庫的版本。
時間一長，使用者的需求總是會改變的。最終可能會要求修改資料庫結構。
把版本信息直接存放到資料庫中更為方便。 

(5) 規格文件(Documents)
對所有的快捷方式、命名規範、限制和函數都要規格文件。
採用給資料表、列、觸發器等加註解的資料庫工具。
對開發、支持和追蹤修改非常有用。

對資料庫文件化，或者在資料庫自身的內部或者單獨建立文件。
這樣，當過了一年多時間後再回過頭來做第2個版本，犯錯的機會將大大減少。

(6) 測試、測試、反覆測試
建立或者修訂資料庫之後，必須用使用者新輸入的資料測試資料欄位。
最重要的是，讓使用者進行測試並且同使用者一道保證選擇的資料類型滿足商業要求。
測試需要在把新資料庫投入實際服務之前完成。

(7) 檢查設計
在開發期間檢查資料庫設計的常用技術是通過其所支持的應用程序原型檢查資料庫。
換句話說，針對每一種最終資料表達資料的原型應用，
保證你檢查了資料模型並且查看如何取出資料。