MYSQL 數據庫定名與設計標准。本站提示廣大學習愛好者:(MYSQL 數據庫定名與設計標准)文章只能為提供參考,不一定能成為您想要的結果。以下是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.數據庫表定名標准
數據表名應用小寫英文和下劃線構成,盡可能解釋是誰人運用或許體系在應用的.
相干運用的數據表應用統一前綴,如服裝論壇t.vhao.net的表應用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) 檢討設計
在開辟時代檢討數據庫設計的經常使用技巧是經由過程其所支撐的運用法式原型檢討數據庫.換句話說,針對每種終究表達數據的原型運用,包管你檢討了數據模子而且檢查若何掏出數據。