在數(shù)據(jù)庫設(shè)計(jì)規(guī)范中，范式和反范式經(jīng)常被提到阻桅。了解范式的概念和原則對我們設(shè)計(jì)數(shù)據(jù)表很有幫助凉倚，然而，范式并不是完美的嫂沉，在實(shí)際開發(fā)中稽寒，經(jīng)常是依據(jù)范式設(shè)計(jì)，再根據(jù)實(shí)際業(yè)務(wù)情況加入反范式設(shè)計(jì)趟章，形成混合模式杏糙。也就是實(shí)際上很少會(huì)有完全的范式設(shè)計(jì)或完全的反范式設(shè)計(jì)。
范式和反范式的區(qū)別
關(guān)于范式的概念蚓土，大家可以自行上網(wǎng)搜索宏侍，大部分情況下是講前面的三大范式：
- 第一范式：每列都具有原子性，意即每一列的含義是不可再拆分的蜀漆，不具備二義性谅河。實(shí)際這個(gè)概念會(huì)依據(jù)也不同而不同，舉個(gè)例子而言，姓名這個(gè)字段本身包含了姓和名旧蛾，如果需要把二者當(dāng)做不同的實(shí)體莽龟，那就需要拆分為兩個(gè)字段；如果不需要那單獨(dú)成一個(gè)字段也沒問題锨天。
- 第二范式：數(shù)據(jù)表每一列都都和主鍵相關(guān)毯盈。這意味著每個(gè)數(shù)據(jù)表不能保存多種實(shí)體數(shù)據(jù)，只保存與本實(shí)體相關(guān)的數(shù)據(jù)病袄。這里的關(guān)鍵是是否需要冗余其他實(shí)體屬性的字段搂赋。
- 第三范式：數(shù)據(jù)表每一列只和主鍵直接相關(guān)而不是間接相關(guān)。也就是數(shù)據(jù)表的列要與數(shù)據(jù)表主鍵代表實(shí)體的直接屬性益缠，而不是關(guān)聯(lián)屬性脑奠。
對于反范式而言，則允許信息冗余或者存放在多個(gè)不同的數(shù)據(jù)表幅慌。以經(jīng)典的人員宋欺、部門和主管為例。最簡單的設(shè)計(jì)是將三者直接放入同一張數(shù)據(jù)表（很多傳統(tǒng)的 Excel 就是按這種方式記錄數(shù)據(jù)）胰伍。
CREATE TABLE t_employees (
employee VARCHAR(32),
department VARCHAR(32),
head VARCHAR(32)
);
這種方式一旦遇到數(shù)據(jù)修改時(shí)會(huì)出現(xiàn)不一致性齿诞。比如張三、李四和王五同在一個(gè)部門骂租，張三的部門主管人員變了祷杈，需要同時(shí)更新李四和王五的數(shù)據(jù)。同時(shí)渗饮，部門必須依賴員工信息才存在但汞，如果刪除了一個(gè)部門的全部員工會(huì)導(dǎo)致部門信息也丟失。為避免這種問題互站，我們就需要建立兩個(gè)實(shí)體表：
CREATE TABLE t_employees (
employee VARCHAR(32),
department VARCHAR(32)
);
CREATE TABLE t_department (
department VARCHAR(32),
head VARCHAR(32)
);
這樣還只是滿足第二范式私蕾，但是已經(jīng)比之前的方式好多了。
范式設(shè)計(jì)的優(yōu)缺點(diǎn)
通常在遇到性能問題的時(shí)候云茸，會(huì)推薦使用范式設(shè)計(jì)是目，范式設(shè)計(jì)具有如下優(yōu)點(diǎn)：
- 數(shù)據(jù)表更新相比反范式而言會(huì)更快。
- 由于沒有冗余數(shù)據(jù)标捺，因此需要更改的數(shù)據(jù)更少懊纳，單表存儲(chǔ)空間也更小。
- 由于缺乏冗余數(shù)據(jù)亡容，意味著使用 DISTINCT 和 GROUP BY 的查詢的需求會(huì)更少嗤疯，可以通過直接查詢相關(guān)的主表完成這類操作。
范式表的缺點(diǎn)在于通常會(huì)需要至少一次的聯(lián)表查詢闺兢，甚至多張表聯(lián)合查詢茂缚。這種代價(jià)不但是高戏罢，還可能導(dǎo)致有些索引策略失效。
反范式設(shè)計(jì)的優(yōu)缺點(diǎn)
反范式表最大的特點(diǎn)是同一張表包含了所有信息脚囊，因此避免了聯(lián)合查詢龟糕。如果不使用聯(lián)合查詢的話，大部分查詢的最糟糕的情況是全表掃描（不使用索引的前提下）悔耘。即便是這樣讲岁，也會(huì)比沒有命中緩存的聯(lián)合查詢快，因?yàn)檫@樣避免了隨機(jī) I/O 訪問衬以。
反范式表的單表索引策略會(huì)更有效缓艳。假設(shè)一個(gè) UGC 的應(yīng)用，其中部分用戶是VIP用戶看峻。然后阶淘，如果想查看VIP用戶的最近的10條信息，如果使用范式數(shù)據(jù)表互妓，并且在發(fā)布日期上使用了索引溪窒，查詢可能是下面的樣子：
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;
執(zhí)行這個(gè)查詢的時(shí)候，MySQL 需要在 published 索引上進(jìn)行掃描车猬，查找到的每一行還需要從用戶表檢查這個(gè)用戶是否是 VIP 用戶霉猛。如果只有少部分用戶是 VIP 的話，那會(huì)非常低效珠闰。而如果使用反范式設(shè)計(jì)的話，可以將用戶賬戶類型冗余到用戶內(nèi)容表中瘫辩，并且添加聯(lián)合索引（account_level, published）伏嗜，這樣就無需使用聯(lián)表查詢了：
SELECT content, user_name
FROM user_content
WHERE account_level='vip'
ORDER BY published DESC LIMIT 10;
當(dāng)然，反范式設(shè)計(jì)也會(huì)有其缺點(diǎn)伐厌，一是數(shù)據(jù)表冗余后會(huì)存儲(chǔ)空間會(huì)變大承绸，二是如果冗余列對應(yīng)的主表發(fā)生了變更，可能需要進(jìn)行大量的數(shù)據(jù)行更新挣轨。例如上面的例子军熏，如果用戶等級從 VIP降為了普通用戶，那對應(yīng)的用戶內(nèi)容表該用戶的數(shù)據(jù)都需要同步更新（當(dāng)然卷扮，也取決于業(yè)務(wù)是否要進(jìn)行同步更新）荡澎。
實(shí)際開發(fā)應(yīng)用
范式設(shè)計(jì)和反范式設(shè)計(jì)都有優(yōu)點(diǎn)和缺點(diǎn)，那該如何選擇呢晤锹？實(shí)際上摩幔，完全的范式設(shè)計(jì)和反范式設(shè)計(jì)只能是實(shí)驗(yàn)室的測試品，而無法在實(shí)際中應(yīng)用鞭铆。在實(shí)際開發(fā)中或衡，通常是二者的混合使用，通常是部分范式數(shù)據(jù)表、緩存表或其他技術(shù)封断。
反范式數(shù)據(jù)設(shè)計(jì)最普遍的形式是冗余斯辰、緩存其他數(shù)據(jù)表的列。例如上面的用戶內(nèi)容表只冗余了用戶賬號等級坡疼，這避免了完全反范式的插入和刪除時(shí)的同步問題彬呻。同時(shí)也使得用戶內(nèi)容表不至于過大，但是提升的效率很明顯回梧。但是废岂，帶來的副作用是更新用戶的賬號等級需要同時(shí)更新用戶內(nèi)容表，這個(gè)就取決于更新用戶等級和查詢的頻率了狱意。
另一個(gè)將數(shù)據(jù)冗余的場景是排序湖苞。例如，用戶內(nèi)容如果需要按作者姓名排序的話详囤，按范式設(shè)計(jì)代價(jià)將十分高昂财骨，而如果在用戶內(nèi)容表冗余作者姓名的話并加上索引，則會(huì)非常高效藏姐。
同樣的隆箩，冗余一些附屬表信息對主表查詢也會(huì)很有幫助，例如假設(shè)我們想知道每個(gè)用戶發(fā)表了多少條內(nèi)容羔杨，就可以在用戶表增設(shè)一個(gè)字段統(tǒng)計(jì)每個(gè)用戶發(fā)布的內(nèi)容條數(shù)捌臊，在用戶每發(fā)布一條內(nèi)容時(shí)更新該字段。這樣如果需要查詢用戶的內(nèi)容條數(shù)或者按用戶內(nèi)容條數(shù)排序時(shí)兜材，就不需要每次都從用戶內(nèi)容表做一次 sum 操作了理澎。
總結(jié)
范式和反范式數(shù)據(jù)庫設(shè)計(jì)本身的理念是值得參考的，通過他們的理念我們可以更清楚地知道數(shù)據(jù)庫該如何設(shè)計(jì)曙寡。在實(shí)際開發(fā)過程中糠爬，需要根據(jù)實(shí)際業(yè)務(wù)來決定主要遵循那種方式。這通常不是整個(gè)數(shù)據(jù)庫遵循一個(gè)范式举庶，而是在數(shù)據(jù)表層級上結(jié)合業(yè)務(wù)执隧，融合二者的優(yōu)缺點(diǎn)綜合考慮。
