对于复杂的计算和聚合，Linq 或 SQL 查询更好吗？答案

【问题标题】：Is better Linq or SQL query for complex calculations and aggregations?对于复杂的计算和聚合，Linq 或 SQL 查询更好吗？
【发布时间】：2018-10-17 16:46:22
【问题描述】：

我们必须在运行时（asp.net mvc）从具有数百万条记录的 Oracle 表数据中创建并显示一些复杂的报告。报告数据必须从分组和很少复杂的计算中获得。那么通过 sql 查询 (pl/sql) 或 linq 进行这些分组和计算的代码的性能和可维护性是否更好？感谢您的kindle回复

【问题讨论】：

这个问题有点太宽泛了。通常我会说数据库在这些计算中更快，但这实际上取决于您的特定要求、数据、硬件等......并权衡可维护性与性能（这肯定意味着速度，而不是记忆）使它更广泛。所以我能给出的最好建议是：race your horses
我同意这个问题太宽泛了。但是考虑到，随着事情变得复杂，有人更容易产生错误的 linq，因为您对幕后生成的脚本的控制较少；一个错误的映射可能会在整个网络中引入整个表，只是为了过滤几条记录（同样，在某些情况下这是预期的行为）。此外，如果您的公司充满了 DBA，但只有一个编码员，最好将所有内容卸载到存储过程:)
我要承认：就代码的可理解性而言，linq 可能更易于阅读和理解。其次，如果将来数据库实现发生变化，您不必检查所有 SQL 以确保它在新的数据库实现中工作。您只需要确保您的 linq 查询是高效的。

标签： performance linq plsql report aggregation

【解决方案1】：

那么它对代码的性能和可维护性更好吗？这些分组和计算是通过 sql 查询 (pl/sql) 还是通过 linq？

这取决于您所说的via linq 是什么意思。如果你的意思是将完整的表提取到本地内存，然后使用 linq 语句提取你想要的结果，那么 SQL 语句当然更快。

但是，如果您的意思是使用实体框架或类似的东西，那么答案并不容易给出。

如果您使用实体框架（或某些克隆），您的表将由IQueryable<...> 表示，而不是IEnumerable<...>。一个IQueryable 有一个Expression 和一个Provider。 Expression 表示必须执行的查询。 Provider 知道哪个系统必须执行查询（通常是数据库管理系统）以及如何与该系统通信。当必须执行查询时，Provider 的任务是将Expression 翻译成系统知道的语言（通常类似于 SQL）并执行 SQL 查询。

有两种 IQueryable LINQ 语句：返回 IQueryable<...> 的语句和返回 TResult 的语句。返回IQueryable 的只更改Expression。它们是使用延迟执行的函数。

不返回 IQueryable 的函数是 ToList()、FirstOrDefault()、Any()、Max() 等。在内部，它们将调用将 GetEnumerator() 的函数（通常通过 foreach），这命令Provider 翻译Expression 并执行查询。

回到你的问题

那么哪个更高效，实体框架还是 SQL？效率不仅是执行查询的时间，也是针对第一个版本和软件未来更改的开发/测试时间。

如果您使用实体框架 (-clone)，则从 Expressions 创建的 SQL 查询非常有效，具体取决于框架制造商。如果您查看代码，那么有时 SQL 查询并不是最佳查询，尽管您必须是一个非常优秀的 SQL 程序员才能改进大多数查询。

在 SQL 语句之上使用 Entity Framework 和 LINQ 查询的最大优势是开发时间会更短。 LINQ 语句的语法在编译时检查，SQL 语句在运行时检查。开发和测试周期会更短。

重用 LINQ 语句很容易，而 SQL 语句几乎总是必须专门针对要执行的查询编写。 LINQ 语句可以在没有数据库的情况下对代表您的表的任何项目序列进行测试。

我的建议

对于大多数查询，您不会注意到实体框架查询或 SQL 查询之间的执行时间有任何差异。

如果您期望复杂的查询和未来的变化，我会选择实体框架。主要论点是更短的开发时间、更好的测试可能性和更好的可维护性。

如果您发现某些查询执行时间过长，您始终可以决定通过执行 SQL 查询而不是使用 LINQ 来绕过实体框架。

如果您将 DbContext 包装在适当的存储库中，在其中隐藏用例的实现，则存储库的用户不会注意到差异。

【讨论】：