優(yōu)秀的庫表設(shè)計，是高性能數(shù)據(jù)庫的基礎(chǔ)
范式：設(shè)計數(shù)據(jù)庫結(jié)構(gòu)過程中所要遵循的規(guī)則和指導(dǎo)方法
六種范式：
1NF、2NF扳躬、3NF、BCNF甚亭、4NF贷币、5NF
常用的范式是前三個
1NF：無重復(fù)的列
2NF：屬于完全依賴于主鍵
3NF：屬性不傳遞依賴于其他非主屬性
后面的范式必須滿足前一個范式
2NF和3NF的區(qū)別
2NF：非主鍵列依賴主鍵
要是有依賴關(guān)系的就是第二范式
3NF：非主鍵列是直接依賴主鍵不是通過傳遞關(guān)系的依賴的
符合這種就是第三范式
將一張大表拆分為三個表
優(yōu)點(diǎn)：
- 避免數(shù)據(jù)冗余
- 避免數(shù)據(jù)庫的空間
- 數(shù)據(jù)變更速度快
缺點(diǎn)： - 范式等級越高，表的數(shù)量越多
- 獲取數(shù)據(jù)時關(guān)聯(lián)過多亏狰，性能較差
反范式：范式設(shè)計表無法滿足性能需求時役纹，需要根據(jù)業(yè)務(wù)場景，在范式的基礎(chǔ)之上靈活設(shè)計
范式化模型：
- 數(shù)據(jù)沒有冗余暇唾，更新容易
1- 表的數(shù)量比較多 - 查詢數(shù)據(jù)需要多表關(guān)聯(lián)時促脉，查詢性能低下
反范式模型：
- 冗余將帶來很好的讀取性能
- 需要維護(hù)冗余數(shù)據(jù)
- 對磁盤空間的消耗是可以接受的
基礎(chǔ)規(guī)范
1.回歸存儲的基本職能
2.查詢時，盡量單表查詢
3.杜絕大事務(wù)策州、大SQL瘸味、大批量、大字段等性能殺手
同一規(guī)范
- 默認(rèn)存儲引擎InnoDB
- 默認(rèn)字符集utf8mb4
- 關(guān)閉大小寫
- 開啟per-table表空間
禁用功能
- eunm够挂、set
- blob旁仿、text
- 視圖、event
- 存儲過程孽糖、觸發(fā)器
命名規(guī)范
名稱的字符范圍為：a-z枯冈，0-9和_(下劃線)
>所有表名小寫
>不允許使用-(橫杠)、空格
>不允許使用其他字符作為名稱
遵循"見名知意"的原則
庫名：1位數(shù)據(jù)庫類型代碼+項(xiàng)目簡稱+識別代碼+序號
出入系統(tǒng)業(yè)務(wù)生產(chǎn)庫：AOCT\AOCT1\AOCT2
出入系統(tǒng)業(yè)務(wù)開發(fā)庫：AOCTDEV\AOCTDEV1\AOCTDEV2
出入系統(tǒng)業(yè)務(wù)測試庫：AOCTEST\AOCTEST1\AOCTEST2
3.png
表的命名規(guī)則
字段名表達(dá)精準(zhǔn)办悟，遵循"見名知意"的原則霜幼，格式：名稱_后綴
避免普遍簡單、有歧義的名稱
布爾型的字段誉尖、以助動詞(has/is)開頭
5.png
程序賬號與數(shù)據(jù)庫名字保持一致
索引命名格式
前綴表名(或縮寫)字段名(或縮寫)
主鍵必須用前綴"pk_"
UNIQUE約束必須用前綴"uk_"
普通索引必須使用前綴"idx_“
數(shù)據(jù)庫表設(shè)計規(guī)范
顯式指定需要的屬性
- 創(chuàng)建表時顯示指定字符集、存儲引擎铸题、注釋信息
不同系統(tǒng)之間铡恕，統(tǒng)一規(guī)范
- 命名琢感、類型保持一致
- 庫表字符集和前端程序、中間件必須保持一致
InnoDB表
- 主鍵列探熔，UNSIGNED整數(shù)驹针，使用auto_increment
- 必須使用comment注釋
- 必須顯示指定engine
- 表必備三字段：id，xxx_create诀艰，xxx_modified
字段規(guī)范
- 合適的類型柬甥，最短的長度，NOT NULL
- 表字段數(shù)少而精
- 單實(shí)例表個數(shù)必須控制在2000個以內(nèi)
- 單表分表個數(shù)必須控制在1024個以內(nèi)
- 單表字段數(shù)上限控制在20-50個
- 禁用ENUM其垄、SET類型苛蒲，采用其他類型替代
- 禁用列為NULL
- 禁止VARBINARY、BLOB存儲圖片绿满、文件等
- 不建議TEXT臂外、BLOB，否則拆分
存儲字符串長度相同的全部使用CHAR類型
變長采用VARCHAR類型喇颁，不預(yù)先分配存儲空間漏健，長度不要超過255
