我的經(jīng)驗告訴我，很多數(shù)據(jù)庫（大多數(shù)我曾經(jīng)使用的）不包含外鍵時并不總是一件壞事。在這篇文章中，我想把重點放在為什么的原因上。

為什么這是一個問題？

1.潛在的數(shù)據(jù)完整性問題，

缺少外鍵明顯問題是數(shù)據(jù)庫不能強制進行引用完整性檢查，如果在高一層沒有正確處理，則可能會導(dǎo)致數(shù)據(jù)不一致（子行沒有相應(yīng)父行）。

2.表格關(guān)系不清晰

數(shù)據(jù)庫中缺少外鍵的另一個不太明顯的負(fù)面影響是，不了解該模式的人很難找到正確的表并找出表關(guān)系。這可能會導(dǎo)致嚴(yán)重的數(shù)據(jù)庫查詢和報告問題。

為什么數(shù)據(jù)庫可以沒有外鍵？

讓我們來看看數(shù)據(jù)庫可以沒有外鍵的原因。首先一個簡短的免責(zé)聲明（因為文章引發(fā)了一些關(guān)于LinkedIn群體的爭議）：

下面的理由絕不鼓勵不要在數(shù)據(jù)庫中使用外鍵約束。這僅僅是我在各種渠道（主要是互聯(lián)網(wǎng)論壇）都能找到的許多開發(fā)人員、架構(gòu)師為什么不使用它們的理由。

我個人（和許多其他經(jīng)驗豐富的數(shù)據(jù)庫專家）建議在任何可能的地方使用它們（不會導(dǎo)致更多的問題）。

1.性能

在表上擁有活動的外鍵可以提高數(shù)據(jù)質(zhì)量，但會影響插入、更新和刪除操作的性能。在這些任務(wù)之前，數(shù)據(jù)庫需要檢查它是否違反數(shù)據(jù)完整性。這就是為什么一些架構(gòu)師和DBA完全放棄外鍵的原因。

數(shù)據(jù)倉庫和分析數(shù)據(jù)庫尤其如此，這些數(shù)據(jù)倉庫和分析數(shù)據(jù)庫不以交易方式（一次一行）處理數(shù)據(jù)，而是批量處理數(shù)據(jù)。性能是數(shù)據(jù)倉庫和商業(yè)智能的一切。

2.傳統(tǒng)數(shù)據(jù)

許多數(shù)據(jù)庫在設(shè)計時需要存儲來自舊數(shù)據(jù)庫和遺留數(shù)據(jù)，這些數(shù)據(jù)可能對數(shù)據(jù)質(zhì)量和完整性沒有那么嚴(yán)格。為了能夠容納舊的臟數(shù)據(jù)，架構(gòu)師可以選擇a）清理和轉(zhuǎn)換遺留數(shù)據(jù)（昂貴的練習(xí)），或者b）放棄在數(shù)據(jù)庫級別上強制執(zhí)行參照完整性。一些打包的ERP和CRM應(yīng)用程序也使用這種方法。

3.全表重新加載

一些數(shù)據(jù)庫，如數(shù)據(jù)倉庫，分段或接口數(shù)據(jù)庫，需要經(jīng)常從外部重新加載數(shù)據(jù)。這會導(dǎo)致重新加載時數(shù)據(jù)不一致（在父表為空的情況下，子表可能已滿載）。這可以通過在重新加載時禁用外鍵來繞過。

然而，這引入了額外的邏輯和復(fù)雜性以及另一個失敗點。如上所述，對性能有負(fù)面影響。通常，成本大于收益，開發(fā)人員不用擔(dān)心外鍵。

4.更高層次的框架

一些應(yīng)用程序使用編程框架，在物理數(shù)據(jù)庫之上創(chuàng)建另一個邏輯層。開發(fā)人員不使用插入或更新語句來修改數(shù)據(jù)，而使用API或者框架在后臺執(zhí)行所有操作。ORM（對象關(guān)系映射）框架或Ruby on Rails框架就是這種情況。

這些工具負(fù)責(zé)參照完整性，并與RDBMS一起創(chuàng)建更高級別的數(shù)據(jù)庫引擎。這些框架可以自己創(chuàng)建數(shù)據(jù)庫表，而不總是創(chuàng)建外鍵。使用這些工具的開發(fā)人員很少會干擾自動生成的模式，并且不需要外鍵。

5.跨數(shù)據(jù)庫關(guān)系

這可能不是數(shù)據(jù)庫沒有外鍵的正確理由，一些數(shù)據(jù)庫跨越更多的物理數(shù)據(jù)庫甚至引擎，并且在技術(shù)上可能不能創(chuàng)建跨越數(shù)據(jù)庫的它不能在同一臺服務(wù)器上的兩個數(shù)據(jù)庫上創(chuàng)建key。

SQL Server就是一個很好的例子 - 它不能在同一臺服務(wù)器上的兩個數(shù)據(jù)庫上創(chuàng)建key。而且這種架構(gòu)在大型系統(tǒng)中很常見。

6.數(shù)據(jù)庫平臺不可知論者

類似于前一個，一些應(yīng)用程序被設(shè)計為數(shù)據(jù)庫平臺（DBMS）不可知的，并能夠在Oracle，SQL Server，DB / 2或Sybase等各種數(shù)據(jù)庫上工作。

這是我讀過的有關(guān)PeopleSoft（目前由Oracle擁有）的內(nèi)容。設(shè)計人員不想綁定到任何特定的平臺，并將所有邏輯推送到應(yīng)用程序?qū)?#xff0c;盡可能清楚地離開數(shù)據(jù)庫層。

7.對更改開放

我與Oracle一直保持緊密聯(lián)系，我聽說過另一個關(guān)于其應(yīng)用程序的故事，這是Oracle自己的產(chǎn)品 - Oracle電子商務(wù)套件 - 就是它被設(shè)計成盡可能定制。

Oracle提供了堅實的基礎(chǔ)，使實施團隊具有彈性，可以盡可能多地決定設(shè)計。至少這是他們所說的。也許這個原因和以前一樣，或者是下一個原因：

8.懶惰的架構(gòu)師

在創(chuàng)建數(shù)據(jù)庫時，如果要存儲數(shù)據(jù)，則需要創(chuàng)建一些表和列。這是最低限度。但是，您不必創(chuàng)建保持?jǐn)?shù)據(jù)一致性的結(jié)構(gòu)，如主鍵，唯一鍵，外鍵或約束。

這需要一些努力，但是卻沒有帶來直接的好處。一些架構(gòu)師和數(shù)據(jù)庫管理員只是忽略了這一部分。

9.保持模型的秘密

也許這是一個很遙遠(yuǎn)的問題，但也許有時候是因為人們不希望別人知道太多太容易。一般來說，人們希望被需要和不可替代。一個完美的自我解釋的設(shè)計可能會使他們過時。但這只是我的理論。

?

來源:www.jdon.com/49188

《新程序員》：云原生和全面數(shù)字化實踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的数据库不推荐使用外键的9个理由！的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。