我們正在設計一個數據庫，我需要考慮一些FK（外鍵） 約束。但不限於 正式結構和規範化。 只有當它提供任何 性能或可擴展性優勢時，我們纔會去做。SQL Server外鍵約束好處
我一直在通過一些有趣的文章和谷歌搜索的實際好處。這裏有一些鏈接：
http://www.mssqltips.com/tip.asp?tip=1296
我想知道更多關於FK的利益（除了正式的結構以及著名的級聯刪除\更新）。
默認情況下FK不是「索引」的，因此索引FK時需要考慮什麼？
如何處理映射爲外鍵的可空字段 - 這是允許的嗎？
除了索引，這是否有助於優化SQL-Server中的查詢執行計劃？
我知道還有更多，但我更喜歡專家對此發表看法。請指導我。
最主要的好處是，如果您的錯誤客戶端代碼嘗試做錯某事，您的數據庫不會最終不一致。外鍵是一種'約束'，所以你應該如何使用它們。
他們沒有任何「功能」的好處，他們不會優化任何東西。您仍然必須自己創建索引等。是的，您可以在作爲外鍵的列中具有NULL值。
不只是buggy的客戶端代碼。 「Buggy」用戶和數據庫管理員在通過直接輸入SQL更新命令進行快速修復時會發生錯誤！ – 2009-10-27 10:20:50
FK約束保持您的數據一致。而已。這是主要的好處。 FK約束不會爲您提供任何性能增益。
但是，除非你有目的數據庫結構非規範化，我建議你使用FK約束。主要原因 - 一致性。
如上所述，它們用於數據完整性。任何性能「損失」將在修復損壞數據所需的時間內完全消除。
但是，可能會有間接的性能收益。
對於SQL Server至少，FK中的列必須在每邊具有相同的數據類型。沒有FK，你可以有一個nvarchar父項和一個varchar子項。當你加入這兩個表時，你會得到一個數據類型轉換，這可能會導致性能下降。
我看了網上的至少一個例子，其中它表明外鍵做提高性能，因爲優化器不具有跨表做額外的檢查，因爲它知道數據是否符合一定的標準已經由於FK。對不起，我沒有鏈接，但博客給出了查詢計劃的詳細輸出以證明它。
我一直在處理一些有數百萬條記錄的數據庫。在數據庫及其克隆之間導入數據很多，然後在Web應用程序環境中使用該克隆。 那麼，我知道保持PK索引自動，所以它有助於加快數據訪問。現在，從這個討論中我得出，如果我在我的SQL查詢中使用JOIN，那麼我會使用FK並對其進行索引以使JOIN操作有效。 – 2009-10-29 14:21:56
例如，我有一個表OrgMaster（包含所有組織記錄），那麼我有一個BookingMaster表（包含所有預訂記錄）。現在，OrmaMaster.Id被「引用」爲BookingMaster.OrgId。所以，我有一個用於OrgId-Id關係的FK，並且爲了在這兩個表格之間的任何JOIN操作獲得更好的性能，我都會'索引'它。我是否正確地得到它？
以上所有 - 以額外的空間和時間開銷爲代價（用FK在表中插入記錄）。 – 2009-10-29 14:22:32
我想請你給我一個要考慮的要點列表，比如 - - FK索引會吃掉太多的空間和時間，因爲表增長了幾百萬條記錄？ - 在這種情況下，是否值得去FK索引「每次」？ - 在什麼情況下shud我不適用FK或指數，或兩者都不它的（當然我可以處理從應用程序很多） - 任何其他棘手用來加快JOIN或其他類似的費時查找？ – 2009-10-29 14:23:06