資料庫-三範式優化與不推薦使用外鍵
什麼是三範式
-
第一範式：「第一範式的數據表必須是二維數據表」，第一範式是指資料庫的每一列都是不可分割的基本數據項，強調列的原子性，某一屬性不能擁有幾個值。比如資料庫的電話號碼屬性裡面不可以有固定電話和行動電話值。 說明：在任何一個關係資料庫中，第一範式（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）和分庫分表時，會省去很多麻煩
