設置數據庫外鍵的一些最佳做法是什麼

在數據庫中設置外鍵約束時，數據庫設計人員應該注意什麼是一些很好的經驗法則和缺陷？設置數據庫外鍵的一些最佳做法是什麼

此外，當繼承現有數據庫並且外鍵很少時，將外鍵添加到現有模式上有多困難？

來源

2011-03-31 Genadinik

使用延遲約束，即使你的DBMS支持它們不允許NULL的外鍵
避免。
考慮添加ON UPDATE CASCADE選項，如果您認爲必須同時考慮替代方案（插入然後更新而不是直接更新候選鍵）。
請注意，添加約束通常比刪除約束更困難。添加約束可能更有可能破壞現有代碼（某些DML可能無法工作），因此可能需要更多開發和測試時間才能解決。因此，最好在每個開發週期的早些時候添加約束條件，而不是稍後添加約束條件 - 以後可以隨時刪除它們。

來源

2011-03-31 15:10:51 sqlvogel

爲什麼在這個世界上，可延遲性很差？ -.5 – 2011-03-31 19:00:11

因爲實際上推遲約束意味着約束不被執行。該事務中的任何代碼都可能看到數據庫處於不一致狀態，這首先破壞了應用約束的目的。 – sqlvogel 2011-04-01 08:29:01

這絕對不正確。延遲約束只有在事務提交之前纔可以延遲。那時每個約束都會被檢查。對於其他每個會話，數據庫都是完全一致的。延遲約束的原因是允許在父項之前創建子記錄。但是在提交之前，父母必須在那裏。 – 2011-04-04 18:28:47

經驗法則，如果您關心數據的完整性，請不要在沒有外鍵關係的情況下建立關係數據庫。是的，這可以減緩數據插入/更新並刪除一些數據。這是一件好事，因爲它正在採取措施來保護您的數據。沒有數據完整性數據庫中所有數據的所有都是不可信的，因此無用。

以後一般不難設置外鍵（在SQL Server中運行Alter table statment來添加鍵），這麼做的困難是爲什麼在設計中不添加它們是不專業的原因相。如果您沒有FK，那麼非常高興您擁有一些不符合PK/FK關係規則的數據，需要首先清理。

來源

2011-03-31 13:39:30 HLGEM

儘管我同意使用foriegn鍵是個好習慣，但我不會說沒有它們的話你的數據就沒用了。在某些情況下不要使用外鍵有很好的理由，特別是如果您需要稍後清除某些數據而不影響通常包含FK關係的其他數據。業務規則並不總是遵循數據規則。但是，這些情況非常罕見。我只是說，沒有FK並不會使你的數據無用，儘管它可能會讓你懷疑。 – 2011-03-31 15:22:14

數據不是無用的，但是你不能證明這一點。通過啓用約束條件，您可以隨時隨地說出事實，即完整性不會受到影響。這是強大的。作爲獎勵，優化器利用約束。實際上，我認爲約束和RI會使數據庫平均速度更快，而不是相反; – Ronnis 2011-03-31 17:41:20

如果您不知道dat是否正確，則無用。這並不意味着它不會被使用，因此使用錯誤的數據會導致糟糕的決定。 – HLGEM 2011-03-31 18:24:19

當你繼承一個模式，你將不得不限制添加到它。（不只是外鍵約束。）
在添加約束之前，有人需要修復壞數據。
需要很長時間修復錯誤數據。（他們有「實」的工作做。）

的第一個數據庫的設計工作，我做了作爲一個專業的是，以取代現有的數據庫爲財富500強又小，即使是上世紀80年代。一些行政人員被分配來解決分析和設計過程中發現的數據錯誤。他們每天可以修復幾百個錯誤。他們並不是一次只想要所有的錯誤，每天只有幾百人。

所以我每天給他們幾百個錯誤。每天六個月。

來源

2011-03-31 14:58:39

我想這是一種更壞的情況。 *經常*你會遇到這樣的情況，但並非總是如此。 – 2011-03-31 15:31:27

實際上它確實很煩人，因爲它只需要1個錯誤就無法啓用約束並享受可用於某些更復雜查詢的真棒優化器轉換。 – Ronnis 2011-03-31 17:39:05

我*喜歡*認爲這是最壞的情況。但我已經看到它發生太多次了;我認爲這是傳統轉換的平均值。 – 2011-04-01 00:15:29

設置數據庫外鍵的一些最佳做法是什麼

回答

相關問題