不推薦資料庫使用外部鍵

1.潛在的資料完整性問題，

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

2.**關係不清晰

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

為什麼資料庫可以沒有外來鍵？

下面的理由絕不鼓勵不要在資料庫中使用外來鍵約束。這僅僅是我在各種渠道（主要是網際網路論壇）都能找到的許多開發人員、架構師為什麼不使用它們的理由。

我個人（和許多其他經驗豐富的資料庫專家）建議在任何可能的地方使用它們（不會導致更多的問題）。

在表上擁有活動的外來鍵可以提高資料質量，但會影響插入、更新和刪除操作的效能。在這些任務之前，資料庫需要檢查它是否違反資料完整性。這就是為什麼一些架構師和dba完全放棄外來鍵的原因。

資料倉儲和分析資料庫尤其如此，這些資料倉儲和分析資料庫不以交易方式（一次一行）處理資料，而是批量處理資料。效能是資料倉儲和商業智慧型的一切。

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

然而，這引入了額外的邏輯和複雜性以及另乙個失敗點。如上所述，對效能有負面影響。通常，成本大於收益，開發人員不用擔心外來鍵。

一些應用程式使用程式設計框架，在物理資料庫之上建立另乙個邏輯層。開發人員不使用插入或更新語句來修改資料，而使用api或者框架在後台執行所有操作。orm（物件關係對映）框架或ruby on rails框架就是這種情況。

這些工具負責參照完整性，並與rdbms一起建立更高階別的資料庫引擎。這些框架可以自己建立資料庫表，而不總是建立外來鍵。使用這些工具的開發人員很少會干擾自動生成的模式，並且不需要外來鍵。

這可能不是資料庫沒有外來鍵的正確理由，一些資料庫跨越更多的物理資料庫甚至引擎，並且在技術上可能不能建立跨越資料庫的它不能在同一臺伺服器上的兩個資料庫上建立key。

sql server就是乙個很好的例子 - 它不能在同一臺伺服器上的兩個資料庫上建立key。而且這種架構在大型系統中很常見。

類似於前乙個，一些應用程式被設計為資料庫平台（dbms）不可知的，並能夠在oracle，sql server，db / 2或sybase等各種資料庫上工作。

這是我讀過的有關peoplesoft（目前由oracle擁有）的內容。設計人員不想繫結到任何特定的平台，並將所有邏輯推送到應用程式層，盡可能清楚地離開資料庫層。

我與oracle一直保持緊密聯絡，我聽說過另乙個關於其應用程式的故事，這是oracle自己的產品 - oracle電子商務套件 - 就是它被設計成盡可能定製。

在建立資料庫時，如果要儲存資料，則需要建立一些表和列。這是最低限度。但是，您不必建立保持資料一致性的結構，如主鍵，唯一鍵，外來鍵或約束。

這需要一些努力，但是卻沒有帶來直接的好處。一些架構師和資料庫管理員只是忽略了這一部分。

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