什麼是使用非Equi加入的有效用例？ >，> =，<, <=, <>

Question

在FROM語句中使用運算符的目的是什麼？在互聯網上提供的大多數例子都可以通過在WHERE語句中加入類似的標準來解決。

舉例：使用WHERE語句

SELECT T1.OrderNum, T1.SpecialOfferAppliedDate AS SOAD, T1.SpecialOfferID, T2.StartDate, T2.EndDate 
FROM OrderDetail AS T1 
    INNER JOIN SpecialOffer AS T2 
     ON T1.SpecialOfferID = T2.SpecialOfferID 
     AND T1.SOAD < T2.EndDate 
     AND T1.SOAD >= T2.StartDate 

例子：

SELECT T1.OrderNum, T1.SpecialOfferAppliedDate AS SOAD, T1.SpecialOfferID, T2.StartDate, T2.EndDate 
FROM OrderDetail AS T1 
    INNER JOIN SpecialOffer AS T2 
      ON T1.SpecialOfferID = T2.SpecialOfferID 
WHERE T1.SOAD < T2.EndDate 
    AND T1.SOAD >= T2.StartDate 

編輯：是否有任何疑問有人可以提供，我將不得不通過非等距加入加入？在這一點上，它似乎只與以下方面有關：HUGE表上的個人偏好或性能增加

Answer 1

早在當時，SQL 2005及其早期版本就取決於如何維護SQL Server，因此可能會聲稱它有時會稍快一些。我已經習慣了這樣做，因爲它對我來說是合乎邏輯的，因爲它可以更快地限制範圍，並首先進入最大的桌面，並獲得更大的壓力。

EG：假設我有三個表A，B，C，並且A和B在Dt（日期）字段中有數百行和一些索引。而另一張桌子只有幾萬行。我想了很多次做這樣的事情：

Select (columns) 
From a 
    inner join b on a.Id = b.FId 
     and a.Id >= (somedate) 
    inner join c on b.Id = c.FId 

它通常對我來說更有意義儘快和發動機方面的限制範圍「發件人」聲明實際上是第一位在SQL Server引擎從我已閱讀和看到。所以我確實在說一千萬數百萬的潛力，然後做一個where語句，只知道內部連接總是說要求必須匹配才能進一步返回和限制範圍。 'Where'子句確實做了同樣的事情，但是在'From'語句之後進行了評估，因此推斷它會更慢是合理的。

但是，在性能與可讀性的開發圈子中經常有爭論。所以，如果我有這樣的事情：

Select (columns) 
From a 
    inner join b on a.Id = b.FId 
     and a.Id >= (somedate) 
     and a.ocol = (criteria) 
    left outer join c on b.Id = c.FId 
where c.ocol = (criteria) 

有人能告訴我：「嗨，哥們，你只得到從0.00001提升，的表現如何只把它所有的Where子句中？」它有時是性能與可讀性的平衡。如果某件事情嚴重滯後，儘管我可以正確地說它可能會更好一些。不過總的來說，我會在2012年左右或者2008年R2閱讀，或者微軟重新編寫引擎，以使編譯效率更高，從本質上講，它不再真正節省時間。您可以自己雖然測試它，如果你想：

運行該SQL上Management Studio中：

SET STATISTICS TIME ON;

你會看到這樣的事情：

SQL Server parse and compile time: 
    CPU time = 0 ms, elapsed time = 2 ms. 

SQL Server Execution Times: 
    CPU time = 0 ms, elapsed time = 0 ms. 

SQL Server Execution Times: 
    CPU time = 0 ms, elapsed time = 2 ms. 

SQL Server Execution Times: 
    CPU time = 0 ms, elapsed time = 0 ms. 

SQL Server Execution Times: 
    CPU time = 0 ms, elapsed time = 8 ms. 

在郵件選項卡。當然，您也可以在視圖面板上操作更加繁重的「客戶統計」選項卡，並查看更多細節。可以說這只是許多人爲了更有效地使用引擎執行來更快地限制範圍而採用的語法技巧。然而，重做可能不會使它變得更好。我仍然使用它，雖然當我自己編碼，你習慣的東西:)

Answer 2

INNER JOIN是您應該使用的ANSI語法。如果可以，避免添加到您的WHERE是最好的。

另外， 它通常被認爲更具可讀性，尤其是當您加入大量表格並且可以在需要時隨時用OUTER JOIN替換。

在性能方面，它們沒有區別。

Answer 3

全部連接可以用WHERE語句重寫，完成所有工作。

SELECT table1.cols ..., table2.cols ... 
FROM table1 
JOIN table2 ON TRUE 
WHERE table1.id = table2.id 

UNION SELECT cols, null ... -- for LEFT or FULL JOIN 
FROM table1 WHERE id NOT IN (SELECT id FROM table2) 

UNION SELECT null ..., cols -- for RIGHT or FULL JOIN 
FROM table2 WHERE id NOT IN (SELECT id FROM table1) 

注意LEFT | RIGHT | FULL JOIN箱子如何更笨重，當您使用WHERE

我個人更喜歡錶達在JOIN ... ON而非WHERE子句中的問題的關係。在您的示例中，可以稱爲「適用於此訂單的特殊優惠」，其中「適用於此訂單」同時包含身份和時間組件。

Answer 4

這都是關於可讀性和可理解性。

將兩個表連接在一起時，將該連接的邏輯保存在一個地方是有意義的。在您的示例中，邏輯匹配記錄依賴於外鍵關係（T1.SpecialOfferID = T2.SpecialOffID）以及購買和特價優惠的日期。日期邏輯似乎是連接的一部分 - 您只想檢索適合該日期範圍的匹配項。

在「where」子句中，您可能有其他限制，不會影響連接邏輯 - 訂單的價值，特價商品的創造者等等。

它通常是一個解釋問題，哪個子句是連接的固有部分，哪些是對數據集的改進。實際上，這兩種用法是等價的。

「非等距」部分是 - 我相信 - 只與它可能定義連接的方式有關。在你的例子中，有一些邏輯表示「與ID匹配的記錄應該也適合在日期範圍內」，以使連接有效「

在join語句中包含比較的用例是業務領域建議這些記錄只有在滿足整個連接條件時才屬於這些記錄。

您將在where子句中包含比較的用例是它改進所需結果的位置，但未定義業務域中哪些記錄「屬於一個」。

Answer 5

副手我想不出任何兩個表格的例子，這些例子自然會與涉及不平等的關係相關。想想我可能會寫的利用使用它們的能力的查詢，仍然不是很難。假設我想按年齡排列人物。爲了簡單，只是假設沒有關係。

select p.name, count(*) as age_rank 
from people p inner join people p2 on p2.birth_date <= p.birth_date 
group by p.name 

許多這些技巧與自我連接的不再需要有先進的SQL功能，如分析功能。

你的問題似乎集中於移動from和where之間的邏輯條件。一旦你開始使用外連接，你不再擁有這種自由，因爲查詢在語義上不再相同。