sql，define與目標表單獨關係或通過連接獲取

Question

我們正在開發一個使用EF和MVC的CMS項目。最近，我們遇到了一個問題，

請考慮以下表格：

• 應用
• 實體
• ProductsCategories
• 產品

的關係是按以下順序：

個應用=>實體=> ProductCategories =>產品

當我們選擇一個產品通過它的Id，總是要檢查是否要求ProductsId是 只是存儲在Applications表中的具體應用，這些是用於防止負載其他應用產品， 什麼是讓特定的應用程序ID產品的最佳方式，我們有兩個選擇：

1. 相反的定義產品和應用之間的關係，我們可以做的加入與productsCategories，實體和應用程序來查找它 =>當我們想要得到我們不想知道實體或其他表，我們應該加入它來訪問應用程序

2. ，我們可以定義產品和應用之間的獨立關係，並通過簡單的把它的產品選擇查詢

哪些是最好的方法，爲什麼？您的評論

---

馬尼什首先謝謝你，那麼請考慮這一點，我們的一些表中沒有與Entities這些表，我們應該定義與entites的關係訪問Applications或定義一個單獨的關係任何關係對於這些表，我們只是定義一個關係，並沒有額外的工作，除了性能問題。還有一些其他表與entites有關係，所以這個定義分離關係有額外的工作， 最後請考慮這一點，實際上所有的表都應該通過單獨的關係訪問'實體'，其他人可以從那裏訪問父母 實際上用於關聯products a nd entities我們沒有定義一個單獨的關係，因爲它沒有性能問題，但對於products和entities之間的關係，我們應該考慮性能問題，因爲在每個請求中我們應該訪問Applications來檢查請求Id是否爲當前應用程序 那麼，你的想法是？

Answer 1

讓我們看看你的選擇

1. 取而代之的定義關係，您可以加入三個表，以獲得正確的產品集：在這種情況下，你不會做任何數據庫更改無論如何，您將不會獲取所有已連接的表格數據，只會提取您在Linq Select列表中指定的數據。但是，如果在某個時間點行數很高，3表連接可能會降低性能

2. 您可以在兩個表格之間定義一個單獨的關係：在這種情況下，您將擁有改變你的數據庫結構，這將意味着，你的實體和實體模型的改變，以及大量的測試。毫無疑問，這將意味着簡單的代碼，易於使用，這總是受歡迎的。

所以你看，沒有明確的答案，最終它取決於你和你的代碼環境，你想要去的，因爲對我來說，我會去創造應用和產品之間的單獨什麼關係實體，這會導致一個更簡潔的代碼，只需少許努力。此外，正如他們所說，「圍繞您的數據結構編碼，而不是其他方式」