2013-02-12 32 views
0

据我所知,至少在SQL Server中,我们不能使用集合中用于与该表连接的表中的别名。为什么别名限制加入集

在一个示例:

CREATE TABLE A (A1 int, A2 int) 
CREATE TABLE B (B1 int, B2 int) 
SELECT a.A2 
FROM 
    A as a 
INNER JOIN 
    (SELECT * FROM B as b WHERE b.B1=a.A1) b2 ON b2.B2=a.A2 

该查询将导致错误因为别名一个在将被连接到该表的一组正在使用其中别名参阅()。

在SQL Server中,这可以通过使用CROSS APPLY或可能通过重写查询来解决。 (这是不是我的问题)。

我的问题是:为什么这个限制存在?,为什么不让让别名使用SQL Server CROSS APPLY

我的第一个猜测是:并行性。如果我们可以限制这一点,那么每个似乎连接的集合总是可以并行计算并加入。但这只是一个猜测。它可以更灵活,让我使用别名和加入集之间的计算依赖关系,我猜想CROSS APPLY

也许没有一个为什么:)

+3

因为'INNER JOIN'不是相关的子查询。 – 2013-02-12 01:11:06

回答

3

的限制,存在由于对标准SQL的范围规则。 from子句中的一个表只是不知道发生了什么里面的另一个表。请记住,SQL是描述性语言不是过程语言。在from子句中的表的顺序并不一定与他们在。

处理此限制不SELECTWHEREHAVING条款适用的实际顺序,因为FROM子句首先计算。

至于cross applyjoin相同或不同。有很多方法可以编写连接,并且显式语法只是其中的一种。相关子查询,select s中的嵌套查询,exists子查询和in子查询都执行关系连接操作的一些变体。他们表达不同。

cross apply与子查询的用途一般也是连接的类型。可能有一些非常复杂的查询的情况下嵌套使用Windows函数,可能无法将查询重写为显式连接。但在大多数情况下,我已经能够做到了。

+0

为什么不能导出连接集之间的依赖关系,并使执行计划与那个对齐呢?答案只是:因为这是通过设计的方式? – 2013-02-12 01:40:49

+0

@PeterTimoz。 。 。你可以那样说。但是SQL语言是由IBM设计的,然后在20世纪80年代由Oracle推广。它实际上基于一些原则,这些原则往往会在成千上万页的文档中迷失方向。它的一些怪癖(和力量)源于这些原则。 ''from'子句元素的独立性就是其中之一。 – 2013-02-12 01:42:45

+0

好的,谢谢你的回答:) – 2013-02-12 01:44:50