挑战:让Linq-to-Entities生成不错的SQL而不需要不必要的连接

Question

我最近在msdn的实体框架论坛上遇到了一个问题:http: //social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/bb72fae4-0709-48f2-8f85-31d0b6a85f68

提出问题的人试图做一个相对简单的查询,涉及两个表,一个分组,一个顺序,以及一个使用Linq-to-Entities的聚合.一个非常简单的Linq查询,并且在SQL中也很简单 - 人们每天都想做的事情.

但是,当使用Linq-to-Entities时,结果是一个复杂的查询,有很多不必要的连接等.我试过它,如果只使用纯Linq,就无法让Linq-to-Entities从中生成一个不错的SQL查询针对EF实体.

从EF看到了相当多的怪物查询我认为可能是OP(以及我和其他人)做错了什么.也许有更好的方法来做到这一点？

所以这是我的挑战:使用来自EF论坛的示例并仅针对这两个实体使用Linq-to-Entities,是否可以让EF生成SQL查询而无需不必要的连接和其他复杂性？

我希望看到EF生成的东西更接近Linq-to-SQL对同类查询所做的事情,同时仍然使用Linq对抗EF模型.

限制:使用EFv1 .net 3.5 SP1或EFv4(beta 1是VS2010/.net4 beta的一部分,可从Microsoft下载).没有CSDL-> SSDL映射技巧,模型'definitionsqueries',存储过程,数据库端函数或允许的视图.只是在模型和数据库之间进行简单的1:1映射,以及执行MSDN上原始线程所要求的纯L2E查询.两个实体之间必须存在关联(即我对原始线程的"解决方法#1"答案不是有效的解决方法)

更新: 500pt赏金添加.玩得开心.

更新:如上所述,使用EFv4/.net 4(β1或更高版本)的解决方案当然有资格获得赏金.如果您使用.net 4postβ1,请包含内部版本号(例如4.0.20605),您使用的L2E查询以及它生成并发送到数据库的SQL.

更新:此问题已在VS2010/.net 4 beta 2中得到修复.虽然生成的SQL仍然有一些[相对无害]额外的嵌套级别,但它不会执行以前的任何坚果.SQL Server优化器完成后的最终执行计划现在已经尽可能好了.+++为负责EFv4的SQL生成部分的家伙和dudettes ...

Answer 1

如果我真的那么担心疯狂的 SQL，我就不会在数据库中进行任何分组。我将首先通过使用 ToList() 完成查询所需的所有数据，同时使用 Include 函数在单个选择中加载所有数据。

这是我的最终结果：

var list = from o in _entities.orderT.Include("personT")
           .Where(p => p.personT.person_id == person_id && 
                       p.personT.created >= fromTime && 
                       p.personT.created <= toTime).ToList()
           group o by new { o.name, o.personT.created.Year, o.personT.created.Month, o.personT.created.Day } into g
           orderby g.Key.name
           select new { g.Key, count = g.Sum(x => x.price) };

这导致选择更加简单：

SELECT 
1 AS [C1], 
[Extent1].[order_id] AS [order_id], 
[Extent1].[name] AS [name], 
[Extent1].[created] AS [created], 
[Extent1].[price] AS [price], 
[Extent4].[person_id] AS [person_id], 
[Extent4].[first_name] AS [first_name], 
[Extent4].[last_name] AS [last_name], 
[Extent4].[created] AS [created1]
FROM    [dbo].[orderT] AS [Extent1]
LEFT OUTER JOIN [dbo].[personT] AS [Extent2] ON [Extent1].[person_id] = [Extent2].[person_id]
INNER JOIN [dbo].[personT] AS [Extent3] ON [Extent1].[person_id] = [Extent3].[person_id]
LEFT OUTER JOIN [dbo].[personT] AS [Extent4] ON [Extent1].[person_id] = [Extent4].[person_id]
WHERE ([Extent1].[person_id] = @p__linq__1) AND ([Extent2].[created] >= @p__linq__2) AND ([Extent3].[created] <= @p__linq__3)

此外，根据提供的示例数据，SQL Profiler 仅注意到 SQL 调用的持续时间增加了 3 毫秒。

就我个人而言，我认为任何抱怨不喜欢 ORM 层的输出 SQL 的人都应该重新使用存储过程和数据集。它们只是还没有准备好进化，需要在众所周知的烤箱中再度过几年。:)