加入查詢，當它太多

我發現我使用了大量的連接查詢，特別是從我的數據庫中獲取有關用戶操作的統計信息。像這樣的查詢並不少見：加入查詢，當它太多

from io in db._Owners where io.tenantId == tenantId 
    join i in db._Instances on io.instanceId equals i.instanceId 
    join m in db._Machines on i.machineId equals m.machineId 
    select ...

我的應用程序仍然不活躍，所以我沒有，如果這些疑問將在現實生活中的計算望而卻步判斷的方式。我的查詢：

是否有限制太多'連接'太多了，可以這樣描述而沒有獲取真實生活中的操作數據？
我的替代品是什麼？例如，創建額外的表來保存我隨時更新的統計信息會更好嗎，而不是每次我需要統計信息時將不同的表源統一起來？

來源

2010-06-30 Testing123

三路連接並不常見。很容易，真實世界的應用程序可以比這更大。 – 2010-06-30 21:26:40

您得到的所有答案都假設這些連接正在SQL內部執行。在使用LinqToSql時，驗證發送的實際查詢以確保您沒有無意中將處理解除到客戶端，這一點很重要。 – hemp 2010-06-30 21:32:01

如果您沒有性能信息，請不要優化。

不成熟的優化是一切邪惡的根源。

1）我認爲你永遠不會達到「極限」。 2）這被稱爲denomalization，如果你不知道問題是否存在，那麼過早非規範化就是浪費精力。

我想說你的查詢看起來很正常。

來源

2010-06-30 21:19:52 jfar

1）是否有這樣做太多的「連接」時的限制太多

沒有，加入的數量不是問題這麼多，因爲在每一個數據結構表，索引的存在和使用以及需要做些什麼來獲取數據。

規範化數據通常是關係數據庫設計的主要目標。您通常會將非規範化視爲僅在必要時優化查詢的手段，因爲需要額外的努力來維護數據的一致性。

如果您真的擔心，請發佈您的數據模型ERD（數據庫表&它們如何關聯）以及您用於項目的數據庫（因爲不是所有數據庫都是相同的）。

來源

2010-06-30 21:24:01

@Ponies：出於好奇，你爲什麼把你的答案標記爲wiki？ – 2010-06-30 21:27:23

@Ken：所以我可以編輯它，當然！ – hemp 2010-06-30 21:29:59

小馬設置它;大麻把它帶回家。 – 2010-06-30 21:38:43

除非你有非常高的流量和索引設置正確等，你應該沒有問題。

對於報告/分析，某些地方會創建一個data warehouse，它的最基本形式是主數據庫的[部分]非規範化副本。由於一張表通常包含大多數（如果不是全部的話）報告中所需的數據，所以它們更容易報告。他們也可以更快地閱讀，因爲你不必加入太多。但是，他們需要更多的磁盤空間（重複數據）。如果允許寫入，它們會變得更慢（必須更新所有重複的數據），並且存在保持重複數據一致的問題。

換句話說，除非你只做報告（或只讀訪問），否則保持連接。

來源

2010-06-30 21:33:09

加入查詢，當它太多

回答

相關問題