2013-02-12 101 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