挑战：让 Linq-to-Entities 生成体面的 SQL，而无需不必要的连接

Question

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

提出问题的人尝试进行一个相对简单的查询，涉及两个表、一个分组、排序依据和一个使用 Linq-to-Entities 的聚合。一个非常简单的 Linq 查询，在 SQL 中也很简单——人们每天都在尝试做的事情。

但是，当使用 Linq-to-Entities 时，结果是一个复杂的查询，其中包含许多不必要的连接等。我尝试了它，但无法让 Linq-to-Entities 从中生成一个像样的 SQL 查询，如果使用只是针对 EF 实体的纯 Linq。

看到来自 EF 的大量怪物查询后，我想也许 OP（还有我，and others）做错了什么。也许有更好的方法来做到这一点？

所以这是我的挑战：使用the example from the EF forum 并仅对两个实体使用 Linq-to-Entities，是否可以让 EF 生成 SQL 查询而无需不必要的连接和其他复杂性？

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

限制：使用 EFv1 .net 3.5 SP1 或 EFv4（beta 1 是 VS2010/.net4 beta 的一部分，可从 Microsoft 下载）。不允许使用 CSDL->SSDL 映射技巧、模型“定义查询”、存储过程、数据库端函数或视图。模型和数据库之间只是简单的 1:1 映射，以及一个纯粹的 L2E 查询，它可以满足 MSDN 上原始线程的要求。两个实体之间必须存在关联（即我对原始线程的“解决方法#1”回答不是有效的解决方法）

更新：增加了 500pt 的赏金。玩得开心。

更新：如上所述，使用 EFv4 / .net 4（β1 或更高版本）的解决方案当然有资格获得赏金。如果您使用的是 .net 4 post β1，请提供内部版本号（例如 4.0.20605）、您使用的 L2E 查询以及它生成并发送到数据库的 SQL。

更新：此问题已在 VS2010 / .net 4 beta 2 中修复。虽然生成的 SQL 仍然有几个 [相对无害的] 额外嵌套级别，但它没有任何作用它曾经的坚果味。在 SQL Server 的优化器尝试之后的最终执行计划现在已经尽可能好。 +++ 为负责 EFv4 的 SQL 生成部分的帅哥和帅哥...

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 的人都应该重新使用存储过程和数据集。它们只是还没有准备好进化，需要在众所周知的烤箱中再呆几年。 :)

Answer 2

有趣的讨论。到目前为止，我已经使用了 2 个 ORM 模型（NHibernate 和 LINQ-to-Entities）。根据我的经验，总有一条线是你必须放弃 ORM 来生成 SQL 并求助于存储过程或视图来实现最佳可扩展查询。话虽如此，我个人认为 LINQ 在更规范化的数据库上效果更好，所有嵌套查询/连接都不是主要问题。在某些情况下，为了提高性能或可伸缩性，您必须使用 DB 服务器功能（例如，在 SQL 2008 SE 上的索引视图仅适用于查询提示），而您根本不能使用 ORM（iBatis 除外？）。

尽管使用 linq 生成的这些嵌套连接/查询不会获得最佳性能或可伸缩性，但请不要忘记 LINQ（或 NHibernate）在任何项目中提供的优势和开发优势。肯定有它的优点。

最后，虽然我冒着比较苹果和橙子的风险，但我认为这更像是在问：您想要快速的网站开发（asp.net webforms、swing）还是对您的 HTML（asp.net mvc、RoR）进行更多控制？选择最适合您要求的东西。

我的 2 美分！

Answer 3

linq 生成的 SQL 非常高效。它可能看起来很笨重，但它考虑到了表和约束等的关系。在我看来，你应该盲目地使用 linq 命令而不用担心规模。自动生成的大型查询有很多好处。它避免了关系约束中的任何失误，并为错误/异常添加了自己的包装器。

如果你想自己编写 SQL 并且仍然想在 ORM 的范围内工作，那么试试 iBatishttp://ibatis.apache.org/ 你必须自己编写 SQL 并加入，所以它可以让你完全控制后端模型.

就个人而言，只需使用 SQLMetal 和 linq。除非您需要，否则不要担心性能和规模。