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

问题描述

VB.NET的Aggregate查询用作具有多个Into子句的Linq表达式的第一个(外部)子句时是否存在致命缺陷，因为每个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?

LINQ to SQL中 SELECT MIN(ZoneMin), MAX(ZoneMin) FROM Plant的显而易见"答案是

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()

但是，此答案实际上是在分开的 SQL查询中检索了Min和Max中的每一个(如果您包括Count和Average之类的其他聚合函数).在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 到

_{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屋！