三範式：就是三個規則
第一範式：確保每列保持原子性
第二範式：確保表中每列都和主鍵相關
第三範式：確保每列都和主鍵列直接相關，而不是間接相關
遵守三範式的目的：為了建立冗餘較小，結構合理的數據庫
第一範式(1NF)
強調的是列的原子性，即列不能夠再分成其他幾列。
第二範式(2NF)
首先是 2NF，另外包含兩部分內容一是表必須有一個主鍵；二是沒有包含在主鍵中的列必須完全依賴於主鍵，而不能只依賴於主鍵的一部分。
第三範式(3NF)
首先是 2NF，另外非主鍵列必須直接依賴於主鍵，不能存在傳遞依賴。即不能存在：非主鍵列 A 依賴於非主鍵列 B，非主鍵列 B 依賴於主鍵的情況。
第三範式通常已經可以滿足業務需求了，表之間的關係也比較清楚了，容易維護。但是為什麼要反範式呢？
首先我們需要了解到定義數據庫範式的歷史背景，在20世紀70年代到80年代範式基本完善定型。在那個時候的系統下：一個硬盤的大小有限，一般也就幾百兆（價格也比較高），上網的人也少，所以範式的理論強調減少依賴，降低冗餘節省空間的使用。而現在最普通的硬盤都是500G，大一點的就上T了而且價格便宜，同時上網人數也增多了，數據庫面臨則高併發，業務邏輯複雜，低延遲的要求。很難在遵循這範式的基礎上進行數據庫設計開發，那麼適當的降低範式，增加冗餘，用空間來換時間是值得的。最低可以把範式降低到1NF。
通常在設計數據庫時遵循以下原則：
1.核心業務使用範式。在類似交易有關的這種敏感核心業務中，強調數據安全和一致性，需要遵循範式保證數據唯一和一致。具體什麼是核心業務視情況而定。
2.弱一致性需求——反ACID。在一些對數據一致性要求不高的場合，不必完全遵循ACID，出現適當的數據不一致是可以容忍的。如在線人數，靜態頁等。當下流行的NoSQL技術，就是基於弱一致性需求，降低數據完整性和一致性換取效率的。
3.空間換時間，冗餘換效率。由於一條可見的記錄被拆分到多個表中記錄，當數據量比較大的時候，聯表查詢就比較費時，sql語句也變的比較複雜，難於優化。此時就需要適當的冗餘了。在統計報表，視圖中就是對這一條規則的體現。統計報表通常會對很多列，有的時候多達上百列，需要對幾個十幾個表進行聯表，數度緩慢，使用人數一多可能會時數據庫服務器宕機。這種情況就需要使用冗餘表了，冗餘表一般符合第一和第二範式。冗餘表一邊是定期轉儲。
4.避免不必要的冗餘。範式理論不是說反就反的，反範式理論不是不要範式，而是在必要時創建冗餘表或者總結表。不必要的冗餘任然是要避免的。所有的規則都是有使用場景的，我們不應該固守規則，在某些情況下，應懂得變通。
閱讀更多 思夢PHP 的文章
