遷移DB：保持關係約束？

Question

冒着被稱爲傻瓜的風險，我想知道你在維護MS SQL DB中的關係約束時的想法。

我正在將系統從ASP遷移到.NET環境中。這帶來了業務對象和其他分層編碼技術，用於從用戶/ API抽象數據庫。新應用程序在實體框架DAL之上有一個確定的API。

舊數據庫中的應用程序數據庫很大，其中一些表的目的將更改爲以文件等形式開始包含二進制數據。我非常希望將這些數據拆分爲單獨的數據庫在磁盤空間非常貴的客戶站點方便管理。

表之間的保留關係約束是否有任何價值？

假設：

• 代碼進行測試
• 凡關係是很重要的，執行事務
• 訪問DB是僅通過API，第三方等訪問不支持下進行的。

理由繼續限制：

• 強制執行的數據結構
• 連接是更快？
• 查詢計劃的幫助？

原因，除去新.NET版本的限制：

• 人們可以假設API/BIZ邏輯將管理關係，如父/子。
• 減少機會數據庫的部分獨立出來到其他目錄
• 難道我相信，SQL有在做其他檢查糾正（系統使用一個插件架構，大多數表可以獨立運行，內置） INSERT約束，當DB上面的API正在管理這個時，這可能是不必要的？

我呼籲社會各界把我的問題反正在情況下，我已經錯過了愚蠢的事情，或者這只是一個等待發生......

非常感謝，

彌敦道

Answer 1

我並不支持這一說法的限制「自動索引」。只有唯一鍵和主鍵。外鍵不會，儘管在大多數情況下，我會建議在與FK列匹配的「子」上使用索引。 不過我還是會建議FKeys因爲他們

1. 將強制執行數據的完整性（我被咬傷BL有錯誤，並沒有做這項工作太多次）。
2. 爲優化程序提供有關數據模式的更多信息，這反過來可能會導致更好更快的執行計劃。

但最重要的是，您是否考慮過將數據保存在單個數據庫中，但將其分隔爲多個文件組？您可以實現更靈活的磁盤空間管理，而不必擔心跨越多個數據庫的外鍵問題

Answer 2

的噩夢是的，我會建議保持關係約束。當然，你必須在你的BLL中處理它們，但是約束也提高了性能，因爲它們被查詢規劃器用來更有效地處理查詢。

也看到這個問題：Are foreign keys really necessary in a database design?

Answer 3

是的，除非您有特定的原因，否則您應該在表上有外鍵約束。即使您的應用程序已經過測試，它也可能不是寫入數據庫的唯一東西。 FK對所有來源的數據執行參照完整性。

外鍵也是數據庫中關係的一種非正式文檔工具。在數據庫中存在FK的情況下，我可以藉助Visio（或任何其他支持逆向工程的工具）設計架構並查看關係。以性能名義在數據庫中放置外鍵是獨立軟件開發商使用的一種常用技術，用於模糊他們的數據庫模式並帶來更多的支持收入。

如果您可以將特定的與性能相關的問題跟蹤到外鍵，則可能需要刪除該鍵。這種情況只發生在一個或兩個特定的高容量表上的少量密鑰上。在交易量非常高的系統上，它也是唯一需要的。在數據庫中根本沒有任何外鍵的藉口。