1.設計原則
1) 標準化和規(guī)范化
數(shù)據(jù)的標準化有助于消除數(shù)據(jù)庫中的數(shù)據(jù)冗余。標準化有好幾種形式，但Third Normal Form（3NF）通常被認為在性能、擴展性和數(shù)據(jù)完整性方面達到了最好平衡。簡單來說，遵守3NF 標準的數(shù)據(jù)庫的表設計原則是：“One Fact in One Place”即某個表只包括其本身基本的屬性，當不是它們本身所具有的屬性時需進行分解。表之間的關系通過外鍵相連接。它具有以下特點：有一組表專門存放通過鍵連接起來的關聯(lián)數(shù)據(jù)。
舉例：某個存放客戶及其有關定單的3NF 數(shù)據(jù)庫就可能有兩個表：Customer和Order。Order表不包含定單關聯(lián)客戶的任何信息，但表內(nèi)會存放一個鍵值，該鍵指向Customer表里包含該客戶信息的那一行。
事實上，為了效率的緣故，對表不進行標準化有時也是必要的。
2) 數(shù)據(jù)驅(qū)動
采用數(shù)據(jù)驅(qū)動而非硬編碼的方式，許多策略變更和維護都會方便得多，大大增強系統(tǒng)的靈活性和擴展性。
舉例，假如用戶界面要訪問外部數(shù)據(jù)源（文件、XML 文檔、其他數(shù)據(jù)庫等），不妨把相應的連接和路徑信息存儲在用戶界面支持表里。還有，如果用戶界面執(zhí)行工作流之類的任務（發(fā)送郵件、打印信箋、修改記錄狀態(tài)等），那么產(chǎn)生工作流的數(shù)據(jù)也可以存放在數(shù)據(jù)庫里。角色權限管理也可以通過數(shù)據(jù)驅(qū)動來完成。事實上，如果過程是數(shù)據(jù)驅(qū)動的，你就可以把相當大的責任推給用戶，由用戶來維護自己的工作流過程。
3) 考慮各種變化
在設計數(shù)據(jù)庫的時候考慮到哪些數(shù)據(jù)字段將來可能會發(fā)生變更。
舉例，姓氏就是如此（注意是西方人的姓氏，比如女性結婚后從夫姓等）。所以，在建立系統(tǒng)存儲客戶信息時，在單獨的一個數(shù)據(jù)表里存儲姓氏字段，而且還附加起始日和終止日等字段，這樣就可以跟蹤這一數(shù)據(jù)條目的變化。
2.數(shù)據(jù)庫涉及字符規(guī)范
采用26個英文字母(區(qū)分大小寫)和0-9這十個自然數(shù),加上下劃線'_'組成,共63個字符.不能出現(xiàn)其他字符(注釋除外).
注意事項:
1) 以上命名都不得超過30個字符的系統(tǒng)限制.變量名的長度限制為29(不包括標識字符@).
2) 數(shù)據(jù)對象、變量的命名都采用英文字符,禁止使用中文命名.絕對不要在對象名的字符之間留空格.
3) 小心保留詞,要保證你的字段名沒有和保留詞、數(shù)據(jù)庫系統(tǒng)或者常用訪問方法沖突
5) 保持字段名和類型的一致性,在命名字段并為其指定數(shù)據(jù)類型的時候一定要保證一致性.假如數(shù)據(jù)類型在一個表里是整數(shù),那在另一個表里可就別變成字符型了.
3.數(shù)據(jù)庫命名規(guī)范
數(shù)據(jù)庫,數(shù)據(jù)表一律使用前綴
正式數(shù)據(jù)庫名使用小寫英文以及下劃線組成,盡量說明是那個應用或者系統(tǒng)在使用的.比如:
web_19floor_net
web_car
備份數(shù)據(jù)庫名使用正式庫名加上備份時間組成,如:
web_19floor_net_20070403
web_car_20070403
4.數(shù)據(jù)庫表命名規(guī)范
數(shù)據(jù)表名使用小寫英文以及下劃線組成,盡量說明是那個應用或者系統(tǒng)在使用的.
相關應用的數(shù)據(jù)表使用同一前綴,如論壇的表使用cdb_前綴,博客的數(shù)據(jù)表使用supe_前綴,前綴名稱一般不超過5字
比如:
web_user
web_group
supe_userspace
備份數(shù)據(jù)表名使用正式表名加上備份時間組成,如:
web_user_20070403
web_group_20070403
supe_userspace_20070403
5.字段命名規(guī)范
字段名稱使用單詞組合完成,首字母小寫,后面單詞的首字母大寫,最好是帶表名前綴.
如 web_user 表的字段:
userId
userName
userPassword
表與表之間的相關聯(lián)字段要用統(tǒng)一名稱,
如 web_user 表里面的 userId 和 web_group 表里面的 userId 相對應
6.字段類型規(guī)范
規(guī)則:用盡量少的存儲空間來存數(shù)一個字段的數(shù)據(jù).
比如能用int的就不用char或者varchar
能用tinyint的就不用int
能用varchar(20)的就不用varchar(255)
時間戳字段盡量用int型，如created:表示從'1970-01-01 08:00:00′開始的int秒數(shù)，采用英文單詞的過去式；gmtCreated:表示datetime類型的時間，即形如'1980-01-01 00:00:00′的時間串，Java中對應的類型為Timestamp
7.數(shù)據(jù)庫設計文檔規(guī)范
所有數(shù)據(jù)庫設計要寫成文檔,文檔以模塊化形式表達.大致格式如下：
‘——————————————-
‘ 表名： web_user
‘ 作者： Aeolus(傻魚)
‘ 日期： 2007-04-11
‘ 版本： 1.0
‘ 描述： 保存用戶資料
‘ 具體內(nèi)容：
‘ UserID int,自動增量 用戶代碼
‘ UserName char(12) 用戶名字
‘ ……
‘——————————————–
8.索引使用原則：
1) 邏輯主鍵使用唯一的成組索引,對系統(tǒng)鍵(作為存儲過程)采用唯一的非成組索引,對任何外鍵列采用非成組索引.考慮數(shù)據(jù)庫的空間有多大,表如何進行訪問,還有這些訪問是否主要用作讀寫.
2) 大多數(shù)數(shù)據(jù)庫都索引自動創(chuàng)建的主鍵字段,但是可別忘了索引外鍵,它們也是經(jīng)常使用的鍵,比如運行查詢顯示主表和所有關聯(lián)表的某條記錄就用得上.
3) 不要索引blob/text等字段,不要索引大型字段(有很多字符),這樣作會讓索引占用太多的存儲空間.
4) 不要索引常用的小型表
不要為小型數(shù)據(jù)表設置任何鍵,假如它們經(jīng)常有插入和刪除操作就更別這樣作了.對這些插入和刪除操作的索引維護可能比掃描表空間消耗更多的時間.
9.sql語句規(guī)范
所有sql關鍵詞全部大寫,比如SELECT,UPDATE,FROM,ORDER,BY等,所有的表名和庫名都要用“包含
如:
SELECT COUNT(*) FROM `cdb_members` WHERE `userName` = ‘a(chǎn)eolus';
10.其他設計技巧
1) 避免使用觸發(fā)器
觸發(fā)器的功能通常可以用其他方式實現(xiàn).在調(diào)試程序時觸發(fā)器可能成為干擾.假如你確實需要采用觸發(fā)器,你最好集中對它文檔化.
2) 使用常用英語(或者其他任何語言)而不要使用編碼或者拼音首字母縮寫
在創(chuàng)建下拉菜單、列表、報表時最好按照英語名排序.假如需要編碼或者拼音首字母縮寫,可以在旁邊附上用戶知道的英語.
3) 保存常用信息
讓一個表專門存放一般數(shù)據(jù)庫信息非常有用.在這個表里存放數(shù)據(jù)庫當前版本、最近檢查/修復(對Access)、關聯(lián)設計文檔的名稱、客戶等信息.這樣可以實現(xiàn)一種簡單機制跟蹤數(shù)據(jù)庫,當客戶抱怨他們的數(shù)據(jù)庫沒有達到希望的要求而與你聯(lián)系時,這樣做對非客戶機/服務器環(huán)境特別有用.
4) 包含版本機制
在數(shù)據(jù)庫中引入版本控制機制來確定使用中的數(shù)據(jù)庫的版本.時間一長,用戶的需求總是會改變的.最終可能會要求修改數(shù)據(jù)庫結構.把版本信息直接存放到數(shù)據(jù)庫中更為方便.
5) 編制文檔
對所有的快捷方式、命名規(guī)范、限制和函數(shù)都要編制文檔.
采用給表、列、觸發(fā)器等加注釋的數(shù)據(jù)庫工具.對開發(fā)、支持和跟蹤修改非常有用.
對數(shù)據(jù)庫文檔化,或者在數(shù)據(jù)庫自身的內(nèi)部或者單獨建立文檔.這樣,當過了一年多時間后再回過頭來做第2 個版本,犯錯的機會將大大減少。
6) 測試、測試、反復測試
建立或者修訂數(shù)據(jù)庫之后,必須用用戶新輸入的數(shù)據(jù)測試數(shù)據(jù)字段.最重要的是,讓用戶進行測試并且同用戶一道保證選擇的數(shù)據(jù)類型滿足商業(yè)要求.測試需要在把新數(shù)據(jù)庫投入實際服務之前完成。
7) 檢查設計
在開發(fā)期間檢查數(shù)據(jù)庫設計的常用技術是通過其所支持的應用程序原型檢查數(shù)據(jù)庫.換句話說,針對每一種最終表達數(shù)據(jù)的原型應用,保證你檢查了數(shù)據(jù)模型并且查看如何取出數(shù)據(jù)。

最新評論