數據庫設計能夠不要外鍵的7個理由

我在大學時上數據庫的課程，學的三個範式中有個第三範式就是專指的外鍵約束。但是出來工做之後第一次作數據庫表設計的時候，組長大佬卻讓我在數據庫中不要使用外鍵，改在代碼中作相應處理。說得專業點，就是不要在數據庫中使用物理外鍵，改成使用邏輯外鍵，即在代碼中寫相關的邏輯代替外鍵所起的做用。我今後便懂得了，解決實際的問題要從實際出發，不能照本宣科。

外鍵的做用

1.外鍵能保證數據的完整性。在沒有外鍵的狀況下，數據庫就不能強制進行引用完整性檢查，若是在高一層沒有進行正確的處理，則可能會致使數據出現不一致的狀況。

2.外鍵能使表之間的關係變得清晰。若是數據庫中缺乏外鍵，不瞭解表之間關係的人很難找到正確的關聯表，這樣可能會致使嚴重的數據庫查詢問題（關聯錯表、查錯表）。

爲何數據庫能夠沒有外鍵

既然外鍵有那麼多好處，爲何這裏說設計數據庫的時候能夠不要外鍵呢，想做死嘛？可是世事無絕對的，這個世界也不是非黑即白的，不少時候人生只能隨波逐流，跟着環境改變。意思就是說，數據庫設計仍是要根據實際狀況，其實有7個理由能夠說明爲何數據庫能夠沒有外鍵。

1.提升性能

在表上擁有活動的外鍵能夠提升數據的質量，可是會影響插入、更新和刪除操做的性能。由於在這些操做任務以前，數據庫須要檢查它是否違反數據完整性。這就是爲何一些架構師和DBA徹底放棄外鍵的緣由。數據倉庫和分析數據庫尤爲如此，這些數據倉庫和分析數據庫不以業務方法（一次一行）處理數據，而是批量處理數據。性能是數據倉庫和商業智能的一切。

2.方便舊數據的導入

許多數據庫在設計的時候須要考慮導入來自舊數據庫的數據的因素。這些數據可能對數據的質量和完整性沒有那麼嚴格，爲了可以容納舊的髒數據，架構師有兩個選擇，一是清理和轉換舊的歷史遺留數據（昂貴代價，須要人工去編制數據）；二是放棄在數據庫級別上強制執行參照完整性。哪一個方法更好更節約成本更高效，我相信已經不言而喻了。

3.方便全表的從新加載

一些數據庫，如數據倉庫，分段或接口數據庫，須要常常從外部從新加載數據。就像你本地的測試數據庫須要從生產環境的正式數據庫從新加載數據同樣。這可能會致使從新加載數據時數據不一致（在父表爲空的狀況下，子表可能已經裝滿）。雖然能夠經過在從新加載數據的時候禁用外鍵來繞過這個問題，然而這卻引入了額外的邏輯和複雜性，以及另外一個失敗點，對性能有負面影響。

4.將外鍵起的做用交給更高層次的框架完成

一些應用程序使用編程框架，在物理數據庫之上建立另外一個邏輯層，開發人員不須要編寫插入或更新語句來修改數據，而是調用提供的API在後臺執行全部操做。ORM（對象關係映射）框架好比Hibernate就是這種狀況，這些框架負責維護參照完整性，並與RDBMS一塊兒建立更高級別的數據庫引擎。

5.方便跨數據庫

在一些大型系統，可能會有不少個數據庫。好比說A表在A數據庫，B表在B數據庫，你想在A表和B表之間建立外鍵是不可能的。固然你可能會說A表和B表要建立外鍵就把A表和B表放在一個數據庫裏面啊，可是我偏不，嘿嘿。

6.節約一些工做成本（偷懶/提升效率）

在建立數據庫的時候，若是要存儲數據，最低限度是要建立一些表和一些字段。可是建立一些保證數據一致性的結構卻不是必須的工做，好比外鍵等約束。這些工做須要人力和時間成本，可是卻沒有帶來直接的好處。所以不少架構師和DBA都選擇忽略掉這一部分。

7.讓你在團隊裏變得不可替代

在現實的社會中，不少人都但願被須要和不可被替代。若是數據庫表的設計者是你且只有你，那麼表之間的關係就只有你知道，別人要知道表之間的關係就只能經過你，你就變成了不可替代的那我的了。固然在現實中是不可能的，數據庫設計都是要留存的，好比說PDM；你也不可能成爲不被替代的那我的。沒有錯，現實就是那麼殘酷。

 

"世界上沒有誰是不可替代的，一我的離開了，立刻就會有另一我的取代他的位置。"

你要去作一個大人，不要回頭，不要難過。