MySQL 數據表設計規范

上一小節介紹了如何設計數據表，并合理選擇字段數據類型新建數據表，本小節來介紹數據表的設計規范，主要遵循數據表設計三范式和適當的反范式化。

1.第一設計范式

第一設計范式要求表中字段都是不可再分的，如果實體中的某個屬性有多個值時，必須拆分為不同的屬性 。通俗理解即一個字段只存儲一項信息，如下圖所示，其中聯系方式可以拆分為手機、郵箱、固定電話，所以下圖不符合數據表第一設計范式要求：

糾正之后符合第一設計范式要求的如下圖所示：

2.第二設計范式

第二設計范式要求表中必須存在業務主鍵，并且全部非主鍵依賴于業務主鍵。第二范式（2NF）是在第一范式（1NF）的基礎上建立起來的，即滿足第二范式（2NF）必須先滿足第一范式（1NF）。第二范式（2NF）要求數據庫表中的每個實例或行必須可以被惟一地區分，為實現區分通常需要我們設計一個主鍵來實現（這里的主鍵不包含業務邏輯）。

即滿足第一范式前提，當存在多個主鍵的時候，才會發生不符合第二范式的情況。比如有兩個主鍵，不能存在這樣的屬性，它只依賴于其中一個主鍵，這就是不符合第二范式。通俗理解是任意一個字段都只依賴表中的同一個字段。（涉及到表的拆分）。如下圖數據表字段中 id 即為業務主鍵：

3.第三設計范式

滿足第三范式（3NF）必須先滿足第二范式（2NF），簡而言之，第三范式（3NF）要求一個數據庫表中不包含已在其它表中已包含的非主鍵字段。就是說表的信息如果能夠被推導出來，就不應該單獨的設計一個字段來存放（能盡量外鍵 join 就用外鍵 join）。很多時候我們為了滿足第三范式往往會把一張表分成多張表。

即滿足第二范式前提，如果某一屬性依賴于其他非主鍵屬性，而其他非主鍵屬性又依賴于主鍵，那么這個屬性就是間接依賴于主鍵，這被稱作傳遞依賴于主屬性。 通俗解釋就是一張表最多只存兩層同類型信息。
如下圖所示的商品表不符合第三設計范式：

如圖所示，商品分類和分類描述字段冗余，每次添加相同分類商品都會使數據重復，浪費存儲空間，可以將表拆分成如下三個表:

遵循數據表設計三范式可以避免字段值的重復存儲，提升存儲效率，節省存儲空間，將各個數據之間分的更細，增加表的冗余性，為后期維護和拓展打下堅實的基礎。高性能的 MySQL 數據庫第一步就是從數據表合理設計開始的。

4.反范式化設計

沒有冗余的數據庫未必是最好的數據庫，有時為了提高運行效率，提高讀性能，就必須降低范式標準，適當保留冗余數據。具體做法是： 在概念數據模型設計時遵守第三范式，降低范式標準的工作放到物理數據模型設計時考慮。降低范式就是增加字段，減少了查詢時的關聯，提高查詢效率，因為在數據庫的操作中查詢的比例要遠遠大于 DML 的比例。但是反范式化一定要適度，并且在原本已滿足三范式的基礎上再做調整的。

如下圖所示，上面的例子可以稍微反范式化設計一下，可以減少實際數據查詢的連表查詢操作，提升效率：

5.小結

本節介紹了數據庫設計三范式，實際工作中，只要遵循數據庫設計第三范式要求即可，數據表的良好設計可以為今后更復雜的業務邏輯減少不必要的麻煩，適當反范式化設計可以提升查詢效率和工作效率。