Piotr Kononow是一位業務分析師、軟件架構師和項目經理，他擁有15年以上編程經驗和背景（SQL，java，C++…）。他的專長是數據倉庫/ BI和商業應用，這是他的一篇文章：
最近我和幾位DBA和架構師爭論，他們對一些數據庫沒有外鍵感到震驚，並聲稱這是一種設計缺陷，是不應該發生的。如果發生必須馬上改正。我想與他們爭辯。我的經驗告訴我，很多數據庫（大多數我曾經使用的）不包含外鍵時並不總是一件壞事。在這篇文章中，我想把重點放在爲什麼的原因上。
爲什麼這是一個問題？
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. 保持模型的祕密
也許這是一個很遙遠的問題，但也許有時候是因爲人們不希望別人知道太多太容易。一般來說，人們希望被需要和不可替代。一個完美的自我解釋的設計可能會使他們過時。但這只是我的理論。
