為什麼我不喜歡資料庫三範式

• 2019 年 10 月 3 日
• 筆記

插曲

最近，一個遠房親戚的小表弟準備選修專業
找到我問：

"哥，現在學資料庫有沒有前途阿?"    "當然有啊，前途大大的呢"  "那我現在開始學資料庫，需要先從什麼開始呢?"    "學課程的話，先了解下資料庫三範式，SQL這些吧"    "SQL我大概知道，資料庫三範式是什麼？"  "阿...三範式就是表的主鍵...唯一性那些東西吧，...嗯，應該就是那些"    "什麼是主鍵？"    "額.....表弟你不要再問了啦，好好去百度一下行不。"    "噢...."  

掛完電話，我舒了口氣，由於差點暴露自己已經不記得三範式了這個不爭的事實，我悄悄打開了Google....

資料庫的這個三範式的概念，相信大多數人都不會陌生，從懵懵懂懂的大學時代就已經普及到教材了（沒記錯的話應該在資料庫系統概論這本教材里）。
還記得那會剛開始找實習的時候，由於自己本事太小，連簡歷都不知道怎麼寫好，尤其是擅長技術的部分更是一片空白。
於是乎會找來隔壁幾個學霸的簡歷來做參考，那會兒大家的簡歷上都會赫赫寫著：

熟練掌握資料庫三範式，精通資料庫系統開發語言。

又或者是：
熟悉ER圖製作工具，能實現滿足三範式的資料庫設計

一開始覺得資料庫三範式確實是個好東西，以至於面試的時候技術官沒有提問到三範式的細節，自己感到了驚訝和茫然。
隨著工作經驗逐漸見長，資料庫範式理論在腦海里的強印象漸漸消除。我在想，要麼是記憶的衰退，要麼就是有些原則已經形成了本能的經驗了。

那麼，什麼是資料庫的範式？

三範式的定義

這裡，不想花太多的篇幅去討論理論性的東西，這些資訊一抓一大把。我們就通過一些簡單的例子來體會一下。

1. 第一範式

假設有一張用戶資訊表，上面除了用戶編號、姓名之外，還會記錄地址資訊：

在這裡面，地址資訊一欄就是不符合第一範式(1NF)的：
第一範式(1NF)：資料庫表的每一列都是不可分割的原子項

因此，應該拆分為：

2. 第二範式

以一個訂單表為例，通常在淘寶上下單時會產生包含多個商品的訂單，如下：

這裡同樣違反了第二範式的定義：
第二範式(2NF)：每個表必須有且僅有一個數據元素為主鍵(Primary key),其他屬性需完全依賴於主鍵

第二範式需建立在滿足第一範式的基礎之上

第二範式首先要求的是存在一個唯一的主鍵，在上面的表中，就必須將 訂單號、商品號 作為一個聯合的主鍵才能滿足要求。
那麼對於第二點要求呢？ 其他屬性是否依賴於這個主鍵？
在訂單的場景中，我們可以認為這算是合理的，因為商品的價格甚至名稱都可能會發生變化，而在每個訂單中所看到的這些資訊都應該是不變的，
誰也不希望看到自己已經支付的訂單中的商品資訊突然大降價.. 當然更重要的還是保持訂單總價與商品單價記錄的一致性。
因此這裡的記錄可以認為是商品資訊在創建訂單時的一個快照。

但是，對於下面的這一場景可能就不合適了：

商品所屬的類別一般是固定的，也就是商品的類別屬性僅僅與商品編號相關，即僅僅是依賴於主鍵的一部分。
這就違反了第二範式中"其他屬性必須完全依賴於主鍵"的規則，因此需要將該屬性分離到商品資訊表中。

3. 第三範式

讓我們回到一開始的用戶表，如果在用戶資訊表中，同時補充一些城市的資訊：

這樣便違反了第三範式的定義：

第三範式(3NF)：數據表中的每一列都和主鍵直接相關，而不能間接相關

同樣，第三範式也需要建立在第二範式的基礎之上

很明顯，這裡的城市人口、特色等屬性都僅僅依賴於用戶所在的城市，而不是用戶，只能算間接的關係。
因此最好的做法是將城市相關的屬性分離到一個城市資訊表中。

為什麼需要範式

資料庫範式為資料庫的設計、開發提供了一個可參考的典範，在許多教學材料中也是作為關鍵的課程內容。
那麼範式的提出是為了解決什麼問題？

• 第一範式，要求將列儘可能最小的分割，希望消除某個列存儲多個值的冗餘的行為
  比如用戶表中的地址資訊，拆分為省、市這種明確的欄位，可以按獨立的欄位檢索、查詢

• 第二範式，要求唯一的主鍵，且不存在對主鍵的部分依賴，希望消除表中存在冗餘(多餘)的列
  比如訂單表中的商品分類、詳情資訊，只需要由商品資訊表存儲一份即可。

• 第三範式，要求沒有間接依賴於主鍵的列，即仍然是希望消除表中冗餘的列
  比如用戶表中不需要存儲額外的 其所在城市的人口、城市特點等資訊。

很明顯，這些範式大都是為了消除冗餘而提出的，這有利於數據的一致性，當然也可以儘可能的減少存儲成本。

PS：你懂得三範式，可以幫老闆省錢，難怪簡歷上要寫上..

除了本文中提到的三範式之外，實質上還有BCNF範式、第四、第五範式。

藉助三範式的理念，你可以設計出很精鍊的資料庫表結構。然而現有的項目應用並不會完全遵循範式的理念，原因比如：

1. 性能原因，沒有任何冗餘的表設計會產生更多的查詢行為，這意味著會產生更多次的資料庫IO操作。在一些實時交互的系統中，可能會慢得讓人難以忍受。
   當然，你可以使用資料庫的 連接(join) 操作，而事實上資料庫提供 join 也就是為了來緩解這種問題。但一旦用到了分庫分表方案，這個問題就會非常的棘手。

2. 成本結構的變化，資料庫範式是在20世紀提出的，當時的磁碟存儲成本還很高。隨著科技發展，數據存儲的成本已經大幅度縮減，對於採用範式設計(規避冗餘)帶來的成本縮減收益已經不那麼明顯。
   See the source image
   

反範式設計

既然範式是為了消除冗餘，那麼反範式就是通過增加冗餘、聚合的手段來提升性能。比如，為了提升查詢的性能，在CMS的文章表中同時冗餘作者的資訊。
冗餘的做法會犧牲一定的數據一致性，通常也是需要業務上進行權衡取捨。

當然，除了冗餘(存儲多份拷貝) 之外，還有另外的理念，即數據的聚合，或者叫嵌套。這種做法相當於是將多個欄位(列)合併存儲到資料庫表的一個列中。

比如一條訂單數據就可以同時包含許多資訊：

{   "oid": "0001",   "price": {    "total": 380,    "benefit": 40   },     "goods": [{     "gid": "SN001",     "name": "藍月亮洗衣液",     "price": 41,     "amount": 2    },    {     "gid": "SN003",     "name": "電動剃鬚刀",     "price": 99,     "amount": 1    }   ],     "address": {    "contact": "張三",    "phone": "150899000"     ...   }  ...  }

這種靈活的結構幾乎是 NoSQL的專利，比如MongoDB文檔資料庫就可以直接以內嵌數組、對象的形式來實現聚合式存儲，這無疑帶來了極大的靈活性。
而 MySQL 在5.7.2版本開始支援JSON結構化列，也進入了聚合式存儲的隊伍，與其對標的PostGreSQL 則是9.4版本就已經支援。

反範式的做法在互聯網項目、開源產品中也比較常見，比如Discuz 的數據表設計中就存在許多的冗餘列、聚合欄位。
一方面，除了能獲得性能的提升之外，數據壓縮、高度靈活擴展(非結構化) 也是反範式設計能獲得青睞的理由。

當然，這裡並非一律反對資料庫範式，理解範式仍然是做好資料庫設計的一門基礎，比如選擇合適的主鍵、清晰的劃分每一列屬性等等。
在項目中仍然需要根據自身的業務特點在範式和反範式中找到平衡點(通常是兩者的結合)。類似於架構設計中空間換時間的一些做法，這其中涉及到的各種取捨都是需要經過權衡的。

也可以說這是一門「藝術「，因為沒有標準答案...