MYSQL 資料庫命名與設計規範

1.設計原則
1) 標準化和正常化
資料的標準化有助於消除資料庫中的資料冗餘。標準化有好幾種形式，但Third Normal Form（3NF）通常被認為在效能、擴充性和資料完整性方面達到了最好平衡。簡單來說，遵守3NF 標準的資料庫的表設計原則是：“One Fact in One Place”即某個表只包括其本身基本的屬性，當不是它們本身所具有的屬性時需進行分解。表之間的關係通過外鍵相串連。它具有以下特點：有一組表專門存放通過鍵串連起來的關聯資料。
舉例：某個存放客戶及其有關定單的3NF 資料庫就可能有兩個表：Customer和Order。Order表不包含定單關聯客戶的任何資訊，但表內會存放一個索引值，該鍵指向Customer表裡包含該客戶資訊的那一行。
事實上，為了效率的緣故，對錶不進行標準化有時也是必要的。
2) 資料驅動
採用資料驅動而非硬式編碼方式，許多策略變更和維護都會方便得多，大大增強系統的靈活性和擴充性。
舉例，假如使用者介面要訪問外部資料源（檔案、XML 文檔、其他資料庫等），不妨把相應的串連和路徑資訊儲存在使用者介面支援表裡。還有，如果使用者介面執行工作流程之類的任務（發送郵件、列印信箋、修改選項組等），那麼產生工作流程的資料也可以存放在資料庫裡。角色許可權管理也可以通過資料驅動來完成。事實上，如果過程是資料驅動的，你就可以把相當大的責任推給使用者，由使用者來維護自己的工作流程過程。
3) 考慮各種變化
在設計資料庫的時候考慮到哪些資料欄位將來可能會發生變更。
舉例，姓氏就是如此（注意是西方人的姓氏，比如女性結婚後從夫姓等）。所以，在建立系統儲存客戶資訊時，在單獨的一個資料表裡儲存姓氏欄位，而且還附加起始日和終止日等欄位，這樣就可以跟蹤這一資料條目的變化。
2.資料庫涉及字元規範
採用26個英文字母(區分大小寫)和0-9這十個自然數,加上底線'_'組成,共63個字元.不能出現其他字元(注釋除外).
注意事項:
1) 以上命名都不得超過30個字元的系統限制.變數名的長度限制為29(不包括標識字元@).
2) 資料對象、變數的命名都採用英文字元,禁止使用中文命名.絕對不要在對象名的字元之間留空格.
3) 小心保留詞,要保證你的欄位名沒有和保留詞、資料庫系統或者常用存取方法衝突
5) 保持欄位名和類型的一致性,在命名欄位並為其指定資料類型的時候一定要保證一致性.假如資料類型在一個表裡是整數,那在另一個表裡可就別變成字元型了.
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) 編製文檔
對所有的捷徑、命名規範、限制和函數都要編製文檔.
採用給表、列、觸發器等加註釋的資料庫工具.對開發、支援和跟蹤修改非常有用.
對資料庫文檔化,或者在資料庫自身的內部或者單獨建立文檔.這樣,當過了一年多時間後再回過頭來做第2 個版本,犯錯的機會將大大減少。
6) 測試、測試、反覆測試
建立或者修訂資料庫之後,必須用使用者新輸入的資料測試資料欄位.最重要的是,讓使用者進行測試並且同使用者一道保證選擇的資料類型滿足商業要求.測試需要在把新資料庫投入實際服務之前完成。
7) 檢查設計
在開發期間檢查資料庫設計的常用技術是通過其所支援的應用程式原型檢查資料庫.換句話說,針對每一種最終表達資料的原型應用,保證你檢查了資料模型並且查看如何取出資料。