Aggregate 是否存在致命缺陷，因为每个 into 子句都是单独执行的? [英] Is Aggregate fatally flawed because each into clause is executed separately?

问题描述

当用作具有多个 Into 子句的 Linq 表达式的第一个(外部)子句时，VB.NET 的 Aggregate 查询是否存在致命缺陷，因为每个 into 子句是单独执行的吗?

Is VB.NET's Aggregate query fatally flawed when used as the first (outer) clause of a Linq expression with multiple Into clauses because each Into clause is executed separately?

SELECT MIN(ZoneMin), MAX(ZoneMin) FROM Plant 在 LINQ 中的明显"答案到 SQL 是

The "obvious" answer to SELECT MIN(ZoneMin), MAX(ZoneMin) FROM Plant in LINQ to SQL is

Dim limits = Aggregate p In Plants Select p.ZoneMin Into Min(), Max()

然而，这个答案实际上检索了 Min 和 Max(如果你包含其他聚合函数，如 Count 和 Average) 在 单独 SQL 查询中.这在 LINQPad 中很容易看到.

However, this answer actually retrieves each of Min and Max (and if you include other aggregate functions like Count and Average) in separate SQL queries. This can be easily seen in LINQPad.

是否存在 LINQPad 未显示的事务(或其他使这些查询原子化的其他事物)，或者这是等待发生的竞争条件?(因此，您必须按照上述问题的答案中显示的技巧来强制执行返回多个聚合的单个查询.)

Is there a transaction (or something else making these queries atomic) not shown by LINQPad, or is this a race condition waiting to happen? (And so you have to do the tricks shown in the answer to the above question to force a single query that returns multiple aggregates.)

总而言之，是否有使用 Aggregate 的 LINQ-to-SQL 查询在单个(或至少是原子")查询中返回多个聚合函数?

In summary, is there a LINQ-to-SQL query using Aggregate that returns multiple aggregate functions in a single (or at least "atomic") query?

<子>(我也说显而易见"，因为对我来说显而易见的答案是，Aggregate p In Plants Into Min(p.ZoneMin), Max(p.ZoneMin)，实际上检索整个表两次，即使在优化时也是如此，然后使用 Linq-to-Entities Min 和 Max 得到结果:-( )

_{(I also say "obvious" because the obvious answer to me, Aggregate p In Plants Into Min(p.ZoneMin), Max(p.ZoneMin), actually retrieves the whole table twice, even when optimised, and then uses the Linq-to-Entities Min and Max to obtain the result :-( )}

_{我认为 Aggregate 不是特定于 VB 的，但看起来 C# 没有这个查询表达式，所以我改变了 .net 到 vb.net.}

_{I thought Aggregate wasn't VB-specific, but it looks like C# does not have this query expression, so I've changed the .net to vb.net.}

推荐答案

回答我更广泛的问题:Aggregate 是否因生成单独的 SQL 查询而没有事务?

To answer my broader question: is Aggregate broken for producing separate SQL queries without transactions?

所有的 LINQ 都可能导致，如果您不仔细调整您的查询以仅产生一个 SELECT，并且如果不放弃"检索更大的结果，这可能是不可能的在单个查询中，然后使用 Linq-to-Objects 聚合或以其他方式操作数据.例如这个查询".

All of LINQ can cause that if you don't carefully adjust your queries to only result in a single SELECT, and that may not be possible, without "giving up", retrieving a larger result in a single query and then using Linq-to-Objects to aggregate or otherwise manipulate the data. This 'query' for example.

因此，通常由程序员来确保围绕可能导致多个查询的 LINQ 查询添加事务.我们只需要确定哪些 LINQ 查询可以转换为多个 SQL 查询即可.

So it is, in general, up to the programmer to ensure transactions are added around LINQ queries that may cause multiple queries. We just need to know for sure which LINQ queries may transform into multiple SQL queries.

这篇关于Aggregate 是否存在致命缺陷，因为每个 into 子句都是单独执行的?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！