使用Linq-to-SQL預加載而無需連接

與許多人一樣，我試圖在保持代碼簡單和可讀性的同時，擠出應用程序的最佳性能。我正在使用Linq-to-SQL，並且確實試圖儘可能保持我的數據層爲聲明式。使用Linq-to-SQL預加載而無需連接

我假設SQL調用是最昂貴的操作。因此，我儘量在數量上儘量減少它們，但要儘量避免難以優化的瘋狂複雜查詢。例如：我使用DataLoadOptions和我的DataContext - 其目標是通過預加載相關實體來最小化查詢數量。（也就是說，急於加載vs延遲加載。）

問題：Linq使用連接來實現目標。與所有事情一樣，這是一種折衷。我越來越少的查詢，但這些加入的查詢更復雜，更昂貴。進入SQL事件探查器清楚地說明了這一點。

所以，我想在Linq選項預加載沒有加入。這可能嗎？這可能是什麼樣的：

我有一個Persons表，Items表和PersonItems表提供多對多的關係。當加載人員集合時，我想要加載所有的PersonItems和Items。

Linq當前使用包含兩個連接的一個大查詢執行此操作。我寧願做的是三個非連接查詢：一個用於人員，一個用於與這些人員相關的所有PersonItems，以及一個用於與這些PersonItem相關的所有項目。然後Linq會自動將它們安排到相關的實體中。

這些都是快速的流水式查詢。長期以來，它將允許可預測的網絡級性能。

看過了嗎？

來源

2010-09-19 Matt Sherman

對於答案還不夠好，但我想我只是想知道爲什麼你似乎對連接有一個自動的負面反應，而沒有通過配置來查看它們是否實際上在性能上更差。另一方面，有人可能會指出，當一個人加入時，使用適當的外鍵來執行多個查詢可以做得更好或更好。最後，代碼可能也會變得更簡單。 – 2010-09-19 20:37:16

夠公平的，雖然我看到複雜性作爲表現的代理。目前它表現良好，但似乎連接必須在費用方面呈指數級增長 - 每個連接乘以x行。這也是性能和規模之間的區別。規模是性能是可預測的，即線性的。 – 2010-09-19 21:27:28

我相信你所描述的三個非連接查詢所做的實質上是在單個連接查詢執行時發生的情況。我可能是錯的，但如果是這種情況，單個查詢將更有效，因爲只涉及一個數據庫查詢而不是三個。如果您遇到性能問題，我會確保您加入的列是索引的（您應該在SQL分析器中看到沒有表掃描）。如果這還不夠，你可以寫一個自定義的存儲過程來獲取你需要的數據（假設你不需要每個對象的每一列，這將允許你使用比索引掃描更快的索引查找），或者你也可以不規則化（表中的重複數據），這樣根本不會發生連接。

來源

2011-03-14 09:35:09 Simon

使用Linq-to-SQL預加載而無需連接

回答

相關問題