私たちは ETL ジョブを開発しており、コンサルタントはテーブルを結合するときに「古いスタイル」の SQL を使用しています。
select a.attr1, b.attr1
from table1 a, table2 b
where a.attr2 = b.attr2
内部結合句を使用する代わりに
select a.attr1, b.attr1
from table1 as a inner join table2 as b
on a.attr2 = b.attr2
私の質問は、長い目で見れば、古い「where join」を使用するリスクはありますか? この種の結合はどのくらいの期間サポートされ、ANSI 標準として保持されますか? 私たちのプラットフォームは SQL Server です。私の主な原因は、将来、これらの "where joins" がサポートされなくなることです。これが発生すると、「内部結合」スタイルの結合を使用して、すべての ETL ジョブを変更する必要があります。
将来起こり得るリスクを心配するよりも、今直面しているリスクを心配してみませんか？
マークのポイントに加えて：
「どこで結合するか」がサポートされなくなるとは思えません。これらはデカルト積と単純なフィルタリングに基づいているため、サポートしないことはできません。それらは実際には結合ではありません。
しかし、新しい結合構文を使用する理由はたくさんあります。とりわけ：
暗黙的な結合を避ける理由はたくさんあります。大きなものは次のとおりです。
すぐに削除されるとは思いませんが、使用をやめる理由は他にもたくさんあります。
どちらの構文も、最新バージョンの ISO SQL (2003、2008) でサポートされています。FROM 句でカンマを使用してクロス結合を指定することは、完全に標準的な SQL であり、私が遭遇したすべての SQL 製品でサポートされています。SQL 内で非推奨または非サポートになる可能性はほとんどないようです。
結合構文に ***= と =* を使用していない限り ( SQL Server 2008 R2 の時点で非推奨になっています)、長期的にはなくなることはありませんが、Mark Byers が言うように、それをしない理由はたくさんあります。
私の最大の懸念は、彼らがこのような結合を書いている場合、彼らは他に何をしていて型にはまらないのでしょうか?
人々はいくつかの良い点を持っていますが、これまでのところ言及されていない2つの大きな点があります:
古いスタイルの *= および =* 外部結合が正しい結果をもたらしたかどうかにかかわらず、それらは特定の結合を適切に示すこともできません。次のクエリを検討してください。$100 を超える注文をしていないすべての顧客を表示したいとします。
SELECT
FROM
Customer C
LEFT JOIN Order O ON C.OrderID = O.OrderID AND O.OrderTotal >= 100.0;
WHERE
O.OrderID IS NULL;
それを古い方法で表現してみてください... できれば。派生テーブルを使用しない。
私にとって、適切な結合句を使用することの大きな価値は、目的の行を返すこのクエリの特別なフィルターから、標準の結合条件 (これら 2 つのテーブルを含むほぼすべてのクエリに適用される) を分離できることです。
SELECT
C.FullName,
C.CustomerCode,
O.OrderDate,
O.OrderTotal,
OD.ExtendedShippingNotes
FROM
Customer C
INNER JOIN Order O ON C.CustomerID = O.CustomerID
INNER JOIN OrderDetail OD ON O.OrderID = OD.OrderID
WHERE
C.CustomerStatus = 'Preferred'
AND O.OrderTotal > 1000.0;
この分離は、クエリを調べている開発者が、このクエリの特徴をスキャンする際に、大量の混乱に対処する必要がないことを意味します。彼がテーブルに精通している場合は、FROM 句を完全にスキップして、WHERE 句を読むだけで必要なすべての情報を取得できます。速いです。そして、目玉でクエリをスキャンするだけであっても、高速化を気にしないのであれば、私はあなたと一緒に働きたくありません.
JOIN 構文を使用する場合、すべての場所に何か特別なものがあると考える人は、それは間違いです。次のクエリは、上のクエリと同じように機能します。
SELECT
C.FullName,
C.CustomerCode,
O.OrderDate,
O.OrderTotal,
OD.ExtendedShippingNotes
FROM
Customer C
CROSS JOIN Order O
INNER JOIN OrderDetail OD
ON C.CustomerID = O.CustomerID
AND C.CustomerStatus = 'Preferred'
AND O.OrderTotal > 1000.0
WHERE
O.OrderID = OD.OrderID;
このクエリには、おそらくまったく同じ実行計画があります。驚いた？しないでください。古いスタイルの構文と同様に、オプティマイザは、指定された条件に基づいてテーブルを結合する方法を見つけ出す役割を果たします。まだ言及されていないテーブルを参照していない限り、条件がどこにあるかは問題ではありません。
では、2 つのスタイルの大きな違いは何でしょうか。上記の 2 番目の混同されたクエリが理解しにくく、クレイジーな書き方だと思う場合は、当然、古いスタイルのクエリは不十分だと思います。率直に言って、古い場所にすべての条件を無作為に入れるのはまとまりがないからです。JOIN の組織システムは理にかなっています。古いスタイルに慣れていて、新しいスタイルがあまり好きではない場合、それはおそらく、変更が (私たち全員にとって) 不快だからです。でも、しばらく使ってしまえば、きっと馴染むと思います。少なくとも、そうでないなら、私にはその理由が理解できません。
特定の構文構造の優雅さや醜さについて議論することは困難です。あなたはそれを見るか見ないかだけです。コンマ区切りの結合構文は、select-project-join クエリの通常の形式を主張するリレーショナル代数の基本的な機能を反映しています。それを回避する唯一の種類の結合 (したがって、専用の構文を保証する) は、外部結合です。結合グラフを不整合にする等式述語の欠落による偶発的な誤りは、フロントエンド SQL プログラミング ツールがどれほど洗練されているか (結合グラフを表示するかどうか) にかかっています。
美学だけではありません。運用データベースでは、CREATED_ON や COMMENTS などの列が多数のテーブルにまたがって存在するのが一般的です。この場合、NATURAL JOIN 構文は明らかに危険です。
Anthony Molinaro (人気のある「SQL Cookbook」の著者) が雄弁に次のように述べています。ANSI はそれを軽視し、しばらくの間開発を行ってきた人々にとって、それは完全に不必要です。」
右結合と左結合の暗黙の構文 *= および =* は推奨されておらず、正当な理由により、現在、常に正しい結果が返されるわけではありません。彼らがこれを使用した場合、これらは現在、誤った結果の危険にさらされているため、今すぐ修正する必要があります。これはオプションではありません。他の構文は引き続き機能しますが、いくつかの理由から同様に置き換える必要があります。まず、間違った結果を返す可能性がある、またはパフォーマンスの問題を引き起こす可能性のあるdistinctを使用して修正される偶発的なクロス結合が非常に簡単に発生します。
もう1つの問題はメンテナンスです。人々が後で他の結合をクエリに追加し、暗黙の結合と明示的な結合を再び混ぜ始めると、間違った結果が得られ、それを認識していないことさえあります。この種のくだらないコードをコードベースに残すのは非常に悪いことです。暗黙の結合も理解するのが難しく、結合を理解していない開発者によって書かれていることが多いため、とにかく必要なものではないかもしれません。また、クエリにクロス結合がある場合、メンテナーはそれがバグ (および偶発的なクロス結合) なのか、意図的なクロス結合 (本当に必要な場合もあります) なのかをどのように知ることができますか? このコードをそのまま受け入れることはできません。私はそれを書いた無能な人が追加料金なしでそれを修正することを主張します.
それらが標準または SQL 製品から削除されるのではないかと心配している場合でも、心配する必要はありません。それは決して起こりそうにありません。
この「古いスタイル」の結合は、まさにそれです。単にスタイルの問題です。それを好む人は、「古いスタイル」の結合の方が理解しやすい状況があることを誓います。私は完全には確信していませんが、1 つ確かなことは、古いスタイルの結合が時々発生し、自分の個人的なスタイルに合わせてコードを再設計することが常に適切であるとは限らないということです。したがって、スタイルに慣れ、それを使用することを学びます。