為什么使用外鍵？

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

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

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

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

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

讓我們來看看數(shù)據(jù)庫(kù)可以沒有外鍵的原因。首先一個(gè)簡(jiǎn)短的免責(zé)聲明（因?yàn)槲恼乱l(fā)了一些關(guān)于LinkedIn群體的爭(zhēng)議）：

下面的理由絕不鼓勵(lì)不要在數(shù)據(jù)庫(kù)中使用外鍵約束。這僅僅是我在各種渠道（主要是互聯(lián)網(wǎng)論壇）都能找到的許多開發(fā)人員、架構(gòu)師為什么不使用它們的理由。我個(gè)人（和許多其他經(jīng)驗(yàn)豐富的數(shù)據(jù)庫(kù)專家）建議在任何可能的地方使用它們（不會(huì)導(dǎo)致更多的問題）。

1.性能

在表上擁有活動(dòng)的外鍵可以提高數(shù)據(jù)質(zhì)量，但會(huì)影響插入、更新和刪除操作的性能。在這些任務(wù)之前，數(shù)據(jù)庫(kù)需要檢查它是否違反數(shù)據(jù)完整性。這就是為什么一些架構(gòu)師和DBA完全放棄外鍵的原因。數(shù)據(jù)倉(cāng)庫(kù)和分析數(shù)據(jù)庫(kù)尤其如此，這些數(shù)據(jù)倉(cāng)庫(kù)和分析數(shù)據(jù)庫(kù)不以交易方式（一次一行）處理數(shù)據(jù)，而是批量處理數(shù)據(jù)。性能是數(shù)據(jù)倉(cāng)庫(kù)和商業(yè)智能的一切。

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

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

3.全表重新加載

一些數(shù)據(jù)庫(kù)，如數(shù)據(jù)倉(cāng)庫(kù)，分段或接口數(shù)據(jù)庫(kù)，需要經(jīng)常從外部重新加載數(shù)據(jù)。這會(huì)導(dǎo)致重新加載時(shí)數(shù)據(jù)不一致（在父表為空的情況下，子表可能已滿載）。這可以通過在重新加載時(shí)禁用外鍵來繞過。然而，這引入了額外的邏輯和復(fù)雜性以及另一個(gè)失敗點(diǎn)。如上所述，對(duì)性能有負(fù)面影響。通常，成本大于收益，開發(fā)人員不用擔(dān)心外鍵。

4.更高層次的框架

一些應(yīng)用程序使用編程框架，在物理數(shù)據(jù)庫(kù)之上創(chuàng)建另一個(gè)邏輯層。開發(fā)人員不使用插入或更新語(yǔ)句來修改數(shù)據(jù)，而使用API或者框架在后臺(tái)執(zhí)行所有操作。ORM（對(duì)象關(guān)系映射）框架或Ruby on Rails框架就是這種情況。這些工具負(fù)責(zé)參照完整性，并與RDBMS一起創(chuàng)建更高級(jí)別的數(shù)據(jù)庫(kù)引擎。這些框架可以自己創(chuàng)建數(shù)據(jù)庫(kù)表，而不總是創(chuàng)建外鍵。使用這些工具的開發(fā)人員很少會(huì)干擾自動(dòng)生成的模式，并且不需要外鍵。

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

這可能不是數(shù)據(jù)庫(kù)沒有外鍵的正確理由，一些數(shù)據(jù)庫(kù)跨越更多的物理數(shù)據(jù)庫(kù)甚至引擎，并且在技術(shù)上可能不能創(chuàng)建跨越數(shù)據(jù)庫(kù)的它不能在同一臺(tái)服務(wù)器上的兩個(gè)數(shù)據(jù)庫(kù)上創(chuàng)建key。SQL Server就是一個(gè)很好的例子 - 它不能在同一臺(tái)服務(wù)器上的兩個(gè)數(shù)據(jù)庫(kù)上創(chuàng)建key。而且這種架構(gòu)在大型系統(tǒng)中很常見。

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

類似于前一個(gè)，一些應(yīng)用程序被設(shè)計(jì)為數(shù)據(jù)庫(kù)平臺(tái)（DBMS）不可知的，并能夠在Oracle，SQL Server，DB / 2或Sybase等各種數(shù)據(jù)庫(kù)上工作。這是我讀過的有關(guān)PeopleSoft（目前由Oracle擁有）的內(nèi)容。設(shè)計(jì)人員不想綁定到任何特定的平臺(tái)，并將所有邏輯推送到應(yīng)用程序?qū)?#xff0c;盡可能清楚地離開數(shù)據(jù)庫(kù)層。

7.對(duì)更改開放

我與Oracle一直保持緊密聯(lián)系，我聽說過另一個(gè)關(guān)于其應(yīng)用程序的故事，這是Oracle自己的產(chǎn)品 - Oracle電子商務(wù)套件 - 就是它被設(shè)計(jì)成盡可能定制。Oracle提供了堅(jiān)實(shí)的基礎(chǔ)，使實(shí)施團(tuán)隊(duì)具有彈性，可以盡可能多地決定設(shè)計(jì)。至少這是他們所說的。也許這個(gè)原因和以前一樣，或者是下一個(gè)原因：

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

在創(chuàng)建數(shù)據(jù)庫(kù)時(shí)，如果要存儲(chǔ)數(shù)據(jù)，則需要?jiǎng)?chuàng)建一些表和列。這是最低限度。但是，您不必創(chuàng)建保持?jǐn)?shù)據(jù)一致性的結(jié)構(gòu)，如主鍵，唯一鍵，外鍵或約束。這需要一些努力，但是卻沒有帶來直接的好處。一些架構(gòu)師和數(shù)據(jù)庫(kù)管理員只是忽略了這一部分。

9.保持模型的秘密

也許這是一個(gè)很遙遠(yuǎn)的問題，但也許有時(shí)候是因?yàn)槿藗儾幌Ｍ麆e人知道太多太容易。一般來說，人們希望被需要和不可替代。一個(gè)完美的自我解釋的設(shè)計(jì)可能會(huì)使他們過時(shí)。

總結(jié)

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

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