在實際實踐中不使用外鍵約束。可以嗎？
不使用 FK 約束是我公司不為人知的規則。FK 約束僅在設計 ERD 時使用，在創建表時不使用。
據我的前輩說，在實際實踐中，當我們處理緊急問題時，這些都是非常耗時的障礙。他說，當我們需要立即使用 INSERT/UPDATE/DELETE 語句時，約束會阻止這些語句被執行，並且在保持約束的同時編寫語句也很耗時。我什至聽說很多其他公司也在這樣做。
雖然我有點理解這些鬥爭，但我不確定這是否是一個好方法，因為它與我對 DB 的理解完全相反。這家公司也是我的第一份工作，所以我不知道其他公司是如何處理的。
實際上，您對此有何看法？這可以說得過去嗎？有沒有更好的方法？其他公司在這件事上是怎麼做的？
更新：對於韓國公司來說，這似乎是一種相當普遍的方法。我問了幾個在其他公司工作的前輩，他們中的大多數人都說他們都是這樣的。甚至其中一個人在一家金融公司工作！有趣的…
沒有什麼是免費的。有時沒有東西也不是免費的。擁有和沒有聲明外鍵都會帶來成本和收益。
外鍵 (FK) 的目的是確保此處的該列只能具有來自該列的值1。通過這種方式，我們可以確保我們只為實際存在的客戶以及我們實際生產和銷售的產品獲取訂單。很多人認為這是一個好主意。
我們在 DBMS 中聲明它們的原因是它可以負責執行它們。它永遠不會允許任何違反規則的數據。此外，它永遠不會讓您擺脫執行規則所需的數據。通過將這項任務委託給機器，我們可以對數據的完整性充滿信心，無論其來源、編寫時間或來自哪個應用程序。當然，這是有代價的。DBMS 必須始終檢查每一行、每個查詢是否遵循規則。這需要時間和精力，這對伺服器來說是一種負擔。它還要求人們按照遵守規則的順序送出 DML。不再狡猾地強制下訂單，然後追上管理員。哦，不是淘氣的人，你必須首先創建客戶，
沒有外鍵，我們可以更自由地做我們可以做的事情，以及我們可以做的事情的順序。可以臨時刪除有問題的行以允許完成關鍵流程。當恐慌結束後，可以對數據進行修補。INSERT 通常會快一點（隨著時間的推移會增加），因為沒有進行 FK 檢查。可以根據需要從數據庫中提取任意數據子集，而無需確保包含所有支持數據。等等。如果相關人員了解系統，仔細記錄，有良好的和解程序，了解後果並有時間自己整理，這絕對沒問題。代價是某處某處被遺漏了一次，並且數據庫惡化為幾乎不可信的垃圾。
一些團隊將檢查放在應用程序而不是數據庫中。同樣，這可以工作。然而，在我看來，使用這種方法，總的伺服器負載將大致相同（或略高），但在某處忘記檢查一些程式碼的風險要高得多。使用 DRI，該規則與電腦通信一次並永久執行。在應用程式碼中，每個新程序都必須重新編寫它。
為了我的兩美分，我完全贊成外鍵。讓電腦做他們擅長的事情，比如例行重複檢查列值是否匹配。我們人類可以專注於夢想新的有趣的東西。幾個月前負責一個系統後，我將 FK 添加到大多數表中。但是，有一些我不會添加它們。這些是我們從外部來源收集數據的地方。拒絕這些行的成本大於接受不良數據並在以後修復它的成本。所以，對於這幾張表，不會有外鍵。我睜大眼睛做這件事，知道我們有監控和糾正程序。
1我承認存在多列外鍵約束。