C# 加入查询并在其'；太多了

我发现我使用了很多连接查询，尤其是从数据库中获取有关用户操作的统计信息。类似这样的查询并不少见：

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 ...

我的应用程序还没有激活，所以我无法判断这些查询在现实生活中是否会在计算上被禁止。我的问题是：

当执行太多的“连接”太多时，是否有限制？在没有获得实际操作统计数据的情况下，是否可以描述这种限制

我的选择是什么？例如，仅仅创建额外的表来保存在我进行更新时更新的统计信息，而不是每次需要统计信息时将不同的表源放在一起，这是否更好

---

如果没有性能信息，则不要进行优化

过早优化是万恶之源

1） 我认为你永远不会达到“极限”。 2） 这就是所谓的去规范化，如果你不知道问题是否存在，过早的去规范化只是白费力气

我认为你的问题看起来很正常

1） 当做太多的“连接”太多时是否有限制

不，联接的数量与其说是一个问题，不如说是每个表中的数据结构、索引的存在和使用以及获取数据需要做些什么

规范化数据通常是关系数据库设计的主要目标。您通常认为非正规化是一种优化查询的手段，因为需要保持数据一致性所需的额外努力。

---

如果你真的担心，发布你的数据模型ERD（数据库表及其关系）和你在项目中使用的数据库（因为并非所有数据库都是相同的）。

除非你有非常高的流量和正确设置的索引等，否则你不应该有问题

对于报告/分析，一些地方将创建一个最基本的形式是主数据库的[部分]非规范化副本。它们更容易报告，因为一个表通常包含报告中所需的大部分（如果不是全部的话）数据。他们也可以更快地阅读，因为你不必加入这么多。但是，它们需要更多的磁盘空间（重复数据）。如果允许写入，则写入速度将变慢（必须更新所有重复数据），并且您将遇到保持重复数据一致性的问题

---

换句话说，除非您只进行报告（或只读访问），否则请保留联接。

三向联接一点也不罕见。现实世界中的应用程序可以很容易地得到比这大得多的结果。你得到的答案都假设这些连接是在SQL内部执行的。使用LinqToSql时，验证发送的实际查询非常重要，以确保不会无意中取消对客户端的处理。@Ponies:出于好奇，为什么将答案标记为wiki？Ponies会设置它；大麻把它带回家。