在數(shù)據(jù)庫設(shè)計(jì)規(guī)范中蒿涎，范式和反范式經(jīng)常被提到哀托。了解范式的概念和原則對(duì)我們?cè)O(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)屬性规婆。
對(duì)于反范式而言澜躺，則允許信息冗余或者存放在多個(gè)不同的數(shù)據(jù)表蝉稳。以經(jīng)典的人員、部門和主管為例掘鄙。最簡(jiǎn)單的設(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ì)變大，二是如果冗余列對(duì)應(yīng)的主表發(fā)生了變更掠械，可能需要進(jìn)行大量的數(shù)據(jù)行更新由缆。例如上面的例子，如果用戶等級(jí)從 VIP降為了普通用戶猾蒂，那對(duì)應(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)室的測(cè)試品蚊逢，而無法在實(shí)際中應(yīng)用限嫌。在實(shí)際開發(fā)中，通常是二者的混合使用时捌，通常是部分范式數(shù)據(jù)表怒医、緩存表或其他技術(shù)。
反范式數(shù)據(jù)設(shè)計(jì)最普遍的形式是冗余奢讨、緩存其他數(shù)據(jù)表的列稚叹。例如上面的用戶內(nèi)容表只冗余了用戶賬號(hào)等級(jí)，這避免了完全反范式的插入和刪除時(shí)的同步問題拿诸。同時(shí)也使得用戶內(nèi)容表不至于過大扒袖，但是提升的效率很明顯。但是亩码，帶來的副作用是更新用戶的賬號(hào)等級(jí)需要同時(shí)更新用戶內(nèi)容表季率，這個(gè)就取決于更新用戶等級(jí)和查詢的頻率了。
另一個(gè)將數(shù)據(jù)冗余的場(chǎng)景是排序描沟。例如飒泻，用戶內(nèi)容如果需要按作者姓名排序的話鞭光，按范式設(shè)計(jì)代價(jià)將十分高昂，而如果在用戶內(nèi)容表冗余作者姓名的話并加上索引泞遗，則會(huì)非常高效惰许。
同樣的，冗余一些附屬表信息對(duì)主表查詢也會(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ù)表層級(jí)上結(jié)合業(yè)務(wù)垃环，融合二者的優(yōu)缺點(diǎn)綜合考慮邀层。
