ORM选择n + 1表现; 加入或不加入

Question

对此有类似的问题,但我认为没有人问过这个问题.

场景:

客户 - 订单(订单具有客户ID) - 订单部分 - 部分

我想要一个查询,它返回一个客户及其所有订单和每个订单及其零件.

现在我有两个主要选择:

1. 使用嵌套循环(生成单独的查询)
2. 使用数据加载选项(产生单个查询连接)

问题:

关于ORM的大多数建议和示例建议使用选项2,我可以看到原因.但是,选项2可能会发回大量重复数据,例如:

选项1结果(3个查询):

ID  Name       Country
1   Customer1  UK

ID  Name
1   Order1
2   Order2

ID  Name
1   Part1
2   Part2
3   Part3

选项2结果(1个查询):

ID  Name       Country  ID  Name    ID Name
1   Customer1  UK       1   Order1  1  Part1
1   Customer1  UK       1   Order1  2  Part2
1   Customer1  UK       1   Order1  3  Part3
1   Customer1  UK       2   Order2  1  Part1
1   Customer1  UK       2   Order2  2  Part2

选项1发回13个字段,包含3个查询.选项2在1个查询中发回42个字段.现在假设Customer表有30个字段,Orders有更复杂的子连接,数据复制很快就会变得庞大.

以下事项对整体性能有何影响:

• 建立数据库连接的开销
• 发送数据所花费的时间(如果在不同的服务器上可能跨网络)
• 带宽

选项2总是最佳选择,选项1是最佳选择还是取决于具体情况？如果取决于,您应该使用什么标准来确定？是否有任何ORM足够聪明地为自己解决问题？

Answer 1

建立数据库连接的开销

如果它们通常位于同一子网上,则很少.如果它们不是那么这仍然不是一个巨大的开销,并且可以通过缓存克服,大多数ORM都有(NHibernate具有一级和二级缓存).

发送数据所花费的时间(如果在不同的服务器上可能跨网络)

因为SELECT N+1这显然会更长,因为每次都必须发送select语句,这可能长达1k.它还必须从池中获取新连接.在2002-2003左右,Chatty与chunky的使用是一个争论,但现在它确实没有太大的区别,除非这是一个非常大的应用程序,在这种情况下你可能想要一个更有经验(或更好付费)的权威人士给出他的观点 - 即顾问.

但是,我赞成加入,因为数据库将在10年或更长时间的开发中针对此用途进行优化.如果性能非常慢,View可以对此进行排序,或者存储过程.

顺便说一句,SELECT N+1可能是人们在第一次开始使用NHibernate时遇到的最常见的性能问题(包括我),并且实际上需要调整才能解决问题.这是因为NHibernate是ORMs C++与语言的对比.

带宽

每个人的额外SELECT声明Customer最终将构建到许多Customer对象*Orders.因此对于大型系统而言,这可能是显而易见的 - 但正如我所提到的,ORM通常具有缓存机制来抵消这个问题.SELECT考虑到以下情况,报表的数量也不会那么大:

• 您大多数时间与SQL服务器位于同一网络中
• 增加的字节数约占额外0.5-50k的额外带宽？想想大多数服务器的速度有多快.