資料庫中沒有外來鍵的9個理由

為什麼這是一個問題？
1.潛在的資料完整性問題，
缺少外來鍵明顯問題是資料庫不能強制進行引用完整性檢查，如果在高一層沒有正確處理，則可能會導致資料不一致（子行沒有相應父行）。

2.表格關係不清晰
資料庫中缺少外來鍵的另一個不太明顯的負面影響是，不瞭解該模式的人很難找到正確的表並找出表關係。這可能會導致嚴重的資料庫查詢和報告問題。

為什麼資料庫可以沒有外來鍵？
讓我們來看看資料庫可以沒有外來鍵的原因。首先一個簡短的免責宣告（因為文章引發了一些關於LinkedIn群體的爭議）：
下面的理由絕不鼓勵不要在資料庫中使用外來鍵約束。這僅僅是我在各種渠道（主要是網際網路論壇）都能找到的許多開發人員、架構師為什麼不使用它們的理由。我個人（和許多其他經驗豐富的資料庫專家）建議在任何可能的地方使用它們（不會導致更多的問題）。

1.效能
在表上擁有活動的外來鍵可以提高資料質量，但會影響插入、更新和刪除操作的效能。在這些任務之前，資料庫需要檢查它是否違反資料完整性。這就是為什麼一些架構師和DBA完全放棄外來鍵的原因。資料倉儲和分析資料庫尤其如此，這些資料倉儲和分析資料庫不以交易方式（一次一行）處理資料，而是批次處理資料。效能是資料倉儲和商業智慧的一切。

2.傳統資料
許多資料庫在設計時需要儲存來自舊資料庫和遺留資料，這些資料可能對資料質量和完整性沒有那麼嚴格。為了能夠容納舊的髒資料，架構師可以選擇a）清理和轉換遺留資料（昂貴的練習），或者b）放棄在資料庫級別上強制執行參照完整性。一些打包的ERP和CRM應用程式也使用這種方法。

3.全表重新載入
一些資料庫，如資料倉儲，分段或介面資料庫，需要經常從外部重新載入資料。這會導致重新載入時資料不一致（在父表為空的情況下，子表可能已滿載）。這可以透過在重新載入時禁用外來鍵來繞過。然而，這引入了額外的邏輯和複雜性以及另一個失敗點。如上所述，對效能有負面影響。通常，成本大於收益，開發人員不用擔心外來鍵。

4.更高層次的框架
一些應用程式使用程式設計框架，在物理資料庫之上建立另一個邏輯層。開發人員不使用插入或更新語句來修改資料，而使用API​​或者框架在後臺執行所有操作。ORM（物件關係對映）框架或Ruby on Rails框架就是這種情況。這些工具負責參照完整性，並與RDBMS一起建立更高階別的資料庫引擎。這些框架可以自己建立資料庫表，而不總是建立外來鍵。使用這些工具的開發人員很少會干擾自動生成的模式，並且不需要外來鍵。

5.跨資料庫關係
這可能不是資料庫沒有外來鍵的正確理由，一些資料庫跨越更多的物理資料庫甚至引擎，並且在技術上可能不能建立跨越資料庫的它不能在同一臺伺服器上的兩個資料庫上建立key。SQL Server就是一個很好的例子 - 它不能在同一臺伺服器上的兩個資料庫上建立key。而且這種架構在大型系統中很常見。

6.資料庫平臺不可知論者
類似於前一個，一些應用程式被設計為資料庫平臺（DBMS）不可知的，並能夠在Oracle，SQL Server，DB / 2或Sybase等各種資料庫上工作。這是我讀過的有關PeopleSoft（目前由Oracle擁有）的內容。設計人員不想繫結到任何特定的平臺，並將所有邏輯推送到應用程式層，儘可能清楚地離開資料庫層。

7.對更改開放
我與Oracle一直保持緊密聯絡，我聽說過另一個關於其應用程式的故事，這是Oracle自己的產品 - Oracle電子商務套件 - 就是它被設計成儘可能定製。Oracle提供了堅實的基礎，使實施團隊具有彈性，可以儘可能多地決定設計。至少這是他們所說的。也許這個原因和以前一樣，或者是下一個原因：

8.懶惰的架構師
在建立資料庫時，如果要儲存資料，則需要建立一些表和列。這是最低限度。但是，您不必建立保持資料一致性的結構，如主鍵，唯一鍵，外來鍵或約束。這需要一些努力，但是卻沒有帶來直接的好處。一些架構師和資料庫管理員只是忽略了這一部分。

9.保持模型的秘密
也許這是一個很遙遠的問題，但也許有時候是因為人們不希望別人知道太多太容易。一般來說，人們希望被需要和不可替代。一個完美的自我解釋的設計可能會使他們過時。但這只是我的理論。

9 Reasons Why There Are No Foreign Keys in Your Da