当您有大量桥接表时测量单个或多个查询的性能答案

【问题标题】：Measuring performance for Single or multiple queries when you have large number of bridge tables当您有大量桥接表时测量单个或多个查询的性能
【发布时间】：2010-12-28 07:51:58
【问题描述】：

我询问了this question 关于单个连接或多个（选择 n + 1）查询

如果您有多对多关系和很多桥接表，我想知道这是否相同

例如，这是我的表格：

表格：人员（id、first、last、age、phone 等）
表：角色（ID、名称）
表：PeopleRoles（id、personID、roleID）
表：技能（ID、姓名）
表：PeopleSkills（id、personID、skillID）

所以如果我加入，我会为每个人获得多行（假设一个人有很多角色或多种技能）。

假设有更多这样的具有许多关系的表，这样会更快：

选项 1：

从应用程序中选择 *
然后遍历每个应用程序并运行 Select * from Roles where applicationID = id inner join

选项 2：

或尝试创建一个返回大型结果集的大型查询，然后在将其转换为数据结构时需要对其进行规范化（因为我当然会在多行中获得相同的应用程序。

【问题讨论】：

标签： sql database-design query-optimization

【解决方案1】：

选项 2几乎总是会更快，只要您没有那么多重复值。这实际上取决于冗余数据的大小——但是当你有大量行时，必须执行多个选择语句确实是死亡之吻，因为它必须执行循环并且不能执行任何更复杂的连接类型在服务器端，但也许更重要的是——如果您的逻辑正在进行许多数据库调用，那么这些调用是跨进程/网络边界发生的，这本身就慢了一个数量级。

如果它真的非常重要，还有其他方法可以优化结果——你可以让数据库创建一些 XML，这些 XML 可以在数据层和逻辑层之间更有效地序列化，但这需要大量的工作和几乎不是任何人所说的跨平台或通用的。

当然，IMO 这一切都引出了问题……为什么不直接使用像 Linq to Entities 或 Linq to SQL 或 (N)Hibernate 这样的 ORM？为什么要重新发明这个轮子？

【讨论】：