什么是三范式
-
第一范式：“第一范式的數據表必須是二維數據表”，第一范式是指數據庫的每一列都是不可分割的基本數據項，強調列的原子性，某一屬性不能擁有幾個值。比如數據庫的電話號碼屬性里面不可以有固定電話和移動電話值。 說明：在任何一個關系數據庫中，第一范式（1NF）是對關系模式的基本要求，不滿足第一范式（1NF）的數據庫就不是關系數據庫。
-
第二范式：建立在第一范式的基礎上，即滿足第二范式一定滿足第一范式，第二范式要求數據表每一個實例或者行必須被唯一標識。除滿足第一范式外還有兩個條件，一是表必須有一個主鍵；二是沒有包含在主鍵中的列必須完全依賴於主鍵，而不能只依賴於主鍵的一部分。每一行的數據只能與其中一列相關，即一行數據只做一件事。只要數據列中出現數據重復，就要把表拆分開來。
-
第三范式：滿足第二范式，且每一個非主屬性都不傳遞依賴於該范式的候選鍵，則稱為第三范式，即不能存在：非主鍵列 A 依賴於非主鍵列 B，非主鍵列 B 依賴於主鍵的情況。
三范式優化
- 主要是滿足第三范式，即不產生數據冗余、插入異常、刪除異常、依賴傳遞等。
拆分表，一張有依賴傳遞的表，如（blog、blog_class、blog_class_description）,拆分成 blog（主表）、blog_class+blog_class_description(依賴關系表)、blog+blog_class(關聯關系表)
反三范式優化
- 反三范式其實是基於三范式所調整的，沒有冗余的數據庫未必是最好的數據庫，完全按照第三范式做表的設計可能會降低查詢效率（涉及多表查詢，多表連接JOIN，臨時表創建GROUP BY），有時候為了提高運行效率，就必須降低范式的標准，適量保留冗余數據。
- 在概念數據模型設計時遵守第三范式，降低范式標准的工作放在物理數據模型時考慮。
- 適當的合並一些表的字段（減少表的數量），產生一些字段冗余，降低了查詢時的關聯，有時候可以提高查詢效率。
- 因為在數據庫操作中，DQL的比例是要遠大於DML的
- 反三范式優化一定要適度，並且是在原本滿足但三范式的基礎上做調整的。
為什么不推薦使用外鍵
外鍵的優點
1、數據一致性
由數據庫自身保證數據一致性、完整性會更可靠。
2、ER圖可靠性、可讀性
有主外鍵的數據庫可以增加數據庫可讀性
外鍵的缺點
1、級聯
在阿里巴巴開發手冊中，就強制要求不允許使用外鍵，所有的外鍵概念必須在應用層解決，因為每次級聯DML操作時，都要級聯操作相關的外鍵表，在高並發場景會導致性能瓶頸。
2、數據庫壓力增加
外鍵等於將數據庫一致性實現，全部交給數據庫服務器完成，有了外鍵，當進行DML操作后，需要出發相關的操作去檢查，應用程序執行的判斷轉移到了數據庫上，增加資源消耗，數據庫性能開銷變大。
3、死鎖
每次修改都要去另外的表檢查數據，獲取額外的鎖。高並發大流量事務場景，使用外鍵可能容易造成死鎖。
4、開發、維護不方便
有外鍵在需要手工維護數據時，都需要考慮級聯問題，數據庫平台遷移（如MySQL遷移到DB2）和分庫分表時，會省去很多麻煩