在數據庫設計規范中，范式和反范式經常被提到。了解范式的概念和原則對我們設計數據表很有幫助，然而，范式并不是完美的，在實際開發中，經常是依據范式設計，再根據實際業務情況加入反范式設計，形成混合模式。也就是實際上很少會有完全的范式設計或完全的反范式設計。
范式和反范式的區別
關于范式的概念，大家可以自行上網搜索，大部分情況下是講前面的三大范式：
- 第一范式：每列都具有原子性，意即每一列的含義是不可再拆分的，不具備二義性。實際這個概念會依據也不同而不同，舉個例子而言，姓名這個字段本身包含了姓和名，如果需要把二者當做不同的實體，那就需要拆分為兩個字段；如果不需要那單獨成一個字段也沒問題。
- 第二范式：數據表每一列都都和主鍵相關。這意味著每個數據表不能保存多種實體數據，只保存與本實體相關的數據。這里的關鍵是是否需要冗余其他實體屬性的字段。
- 第三范式：數據表每一列只和主鍵直接相關而不是間接相關。也就是數據表的列要與數據表主鍵代表實體的直接屬性，而不是關聯屬性。
對于反范式而言，則允許信息冗余或者存放在多個不同的數據表。以經典的人員、部門和主管為例。最簡單的設計是將三者直接放入同一張數據表（很多傳統的 Excel 就是按這種方式記錄數據）。
CREATE TABLE t_employees (
employee VARCHAR(32),
department VARCHAR(32),
head VARCHAR(32)
);
這種方式一旦遇到數據修改時會出現不一致性。比如張三、李四和王五同在一個部門，張三的部門主管人員變了，需要同時更新李四和王五的數據。同時，部門必須依賴員工信息才存在，如果刪除了一個部門的全部員工會導致部門信息也丟失。為避免這種問題，我們就需要建立兩個實體表：
CREATE TABLE t_employees (
employee VARCHAR(32),
department VARCHAR(32)
);
CREATE TABLE t_department (
department VARCHAR(32),
head VARCHAR(32)
);
這樣還只是滿足第二范式，但是已經比之前的方式好多了。
范式設計的優缺點
通常在遇到性能問題的時候，會推薦使用范式設計，范式設計具有如下優點：
- 數據表更新相比反范式而言會更快。
- 由于沒有冗余數據，因此需要更改的數據更少，單表存儲空間也更小。
- 由于缺乏冗余數據，意味著使用 DISTINCT 和 GROUP BY 的查詢的需求會更少，可以通過直接查詢相關的主表完成這類操作。
范式表的缺點在于通常會需要至少一次的聯表查詢，甚至多張表聯合查詢。這種代價不但是高，還可能導致有些索引策略失效。
反范式設計的優缺點
反范式表最大的特點是同一張表包含了所有信息，因此避免了聯合查詢。如果不使用聯合查詢的話，大部分查詢的最糟糕的情況是全表掃描（不使用索引的前提下）。即便是這樣，也會比沒有命中緩存的聯合查詢快，因為這樣避免了隨機 I/O 訪問。
反范式表的單表索引策略會更有效。假設一個 UGC 的應用，其中部分用戶是VIP用戶。然后，如果想查看VIP用戶的最近的10條信息，如果使用范式數據表，并且在發布日期上使用了索引，查詢可能是下面的樣子：
SELECT content, user_name
FROM user_content
INNER JOIN user on user_content.user_id=user.id
WHERE user.account_level='vip'
ORDER BY user_content.published DESC LIMIT 10;
執行這個查詢的時候，MySQL 需要在 published 索引上進行掃描，查找到的每一行還需要從用戶表檢查這個用戶是否是 VIP 用戶。如果只有少部分用戶是 VIP 的話，那會非常低效。而如果使用反范式設計的話，可以將用戶賬戶類型冗余到用戶內容表中，并且添加聯合索引（account_level, published），這樣就無需使用聯表查詢了：
SELECT content, user_name
FROM user_content
WHERE account_level='vip'
ORDER BY published DESC LIMIT 10;
當然，反范式設計也會有其缺點，一是數據表冗余后會存儲空間會變大，二是如果冗余列對應的主表發生了變更，可能需要進行大量的數據行更新。例如上面的例子，如果用戶等級從 VIP降為了普通用戶，那對應的用戶內容表該用戶的數據都需要同步更新（當然，也取決于業務是否要進行同步更新）。
實際開發應用
范式設計和反范式設計都有優點和缺點，那該如何選擇呢？實際上，完全的范式設計和反范式設計只能是實驗室的測試品，而無法在實際中應用。在實際開發中，通常是二者的混合使用，通常是部分范式數據表、緩存表或其他技術。
反范式數據設計最普遍的形式是冗余、緩存其他數據表的列。例如上面的用戶內容表只冗余了用戶賬號等級，這避免了完全反范式的插入和刪除時的同步問題。同時也使得用戶內容表不至于過大，但是提升的效率很明顯。但是，帶來的副作用是更新用戶的賬號等級需要同時更新用戶內容表，這個就取決于更新用戶等級和查詢的頻率了。
另一個將數據冗余的場景是排序。例如，用戶內容如果需要按作者姓名排序的話，按范式設計代價將十分高昂，而如果在用戶內容表冗余作者姓名的話并加上索引，則會非常高效。
同樣的，冗余一些附屬表信息對主表查詢也會很有幫助，例如假設我們想知道每個用戶發表了多少條內容，就可以在用戶表增設一個字段統計每個用戶發布的內容條數，在用戶每發布一條內容時更新該字段。這樣如果需要查詢用戶的內容條數或者按用戶內容條數排序時，就不需要每次都從用戶內容表做一次 sum 操作了。
總結
范式和反范式數據庫設計本身的理念是值得參考的，通過他們的理念我們可以更清楚地知道數據庫該如何設計。在實際開發過程中，需要根據實際業務來決定主要遵循那種方式。這通常不是整個數據庫遵循一個范式，而是在數據表層級上結合業務，融合二者的優缺點綜合考慮。
