私はSQLの結合を理解するのに問題があり、この画像に出くわした. 問題は、私がそれを完全に理解していないことです。たとえば、画像の右上隅にある結合では、B の円全体が赤く色付けされていますが、A からのオーバーラップのみが表示されています。この画像では、円 B が SQL ステートメントの主要な焦点であるように見えますが、SQL ステートメントはA から始める (A から選択し、B を結合する) こと自体は、私には反対の印象を与えます。つまり、A が sql ステートメントの焦点になるということです。
同様に、B サークルからのデータのみを含む下の画像では、なぜ A が結合ステートメントに含まれているのでしょうか?
質問: 右上から時計回りに作業し、中央で終了します。誰かが各 SQL イメージの表現に関する詳細情報を提供してくれますか?
a) それぞれの場合に結合が必要な理由 (たとえば、特に A または B からデータが取得されていない場合、つまり、両方ではなく A または B のみが色付けされている場合)
b）および画像がSQLの適切な表現である理由を明確にするその他の詳細
ここでのベン図の制限については Cade に同意します。より適切な視覚的表現はこれかもしれません。
クロス結合 (またはデカルト積) は、2 つのテーブルの行のすべての組み合わせで結果を生成します。各テーブルには 4 行あるため、結果として 16 行が生成されます。
内部結合は、結合条件に一致するクロス結合からすべての行を論理的に返します。この場合は 5 つです。
内部結合条件は必ずしも等価条件である必要はなく、両方 (またはどちらか) のテーブルから列を参照する必要もありません。A.Colour NOT IN ('Green','Blue')交差結合の各行を評価すると戻ります。
内部結合条件は1=1、クロス結合のすべての行に対して true と評価されるため、2 つが同等になります ( SQL Fiddle )。
外部結合は内部結合と同じ方法で論理的に評価されますが、左側のテーブルの行 (左側の結合の場合) が右側のテーブルの行とまったく結合しない場合、その行は結果に保持されNULL、右側の列。
これは、前の結果を単純に制限して、B.Colour IS NULL. この特定のケースでは、これらは右側のテーブルで一致しなかったため保持された行になり、クエリは table で一致しない単一の赤い行を返しますB。これは、反セミ結合として知られています。
このパターンが正しく機能し、たまたまその値を持つ行を戻すことを避けるためにIS NULL、null 許容でないか、結合条件によってすべての値が除外されることが保証されるテスト用の列を選択することが重要です。一致しない行に加えて列。NULLNULL
右外部結合は、右テーブルの一致しない行を保持し、左側の列を null 拡張することを除いて、左外部結合と同様に機能します。
完全外部結合は、左右の結合の動作を組み合わせて、左右のテーブルの一致しない行を保持します。
あなたの主な根本的な混乱は、（たとえば）のみAが赤で強調表示されている場合、それを「クエリは次のデータのみを返す」ことを意味していると思いますが、実際にはA「クエリは次の場合のデータのみを返す」ことを意味します」Aという記録があります。クエリには B からのデータがまだ含まれている可能性があります ( にレコードがない場合B、クエリは に置き換えられNULLます)。
同様に、B サークルからのデータのみを含む下の画像では、なぜ A が結合ステートメントに含まれているのでしょうか?
つまり、画像A全体が白で、 とB重ならない部分に赤い三日月形がある場合、クエリに表示されるA理由は、必要なレコードを見つける方法です。除外されます。(クエリに表示されない場合、ベン図には がなく、 のみが表示され、必要なレコードと不要なレコードを区別する方法がありません。)AABAAB
このイメージでは、円 B が sql ステートメントの主要な焦点のように見えますが、SQL ステートメント自体は、A で始まる (A から選択し、B を結合する) ことにより、逆の印象、つまり A が焦点になるという印象を私に伝えます。 sqlステートメントの。
その通りです。このため、RIGHT JOINは比較的まれです。a を使用するクエリは、LEFT JOINほとんどの場合、代わりに a を使用するように並べ替えることができますがRIGHT JOIN(逆も同様です)、通常、人々はクエリをLEFT JOINではなく で記述しRIGHT JOINます。
ベン図は、UNION、INTERSECTS、EXCEPT などの集合操作を表すのに適しています。
EXCEPT のような集合操作が LEFT JOIN WHERE rhs.KEY が NULL のようなものでシミュレートされるという範囲でのみ、この図は正確です。
そうでなければ、それは誤解を招くものです。たとえば、結合条件が 1:1 でない場合、どの結合でも行が乗算される可能性があります。ただし、セットには個別のメンバーしか含めることができないため、セット操作として表すことはできません。
次に、CROSS JOIN または INNER JOIN ON 1 = 1 があります。これは、この図に示されている INNER JOIN とは類似しておらず、生成されるセットをベン図で実際に説明することもできません。他のすべての可能な三角結合、自己および反結合は言うまでもありません。
lhs INNER JOIN rhs ON rhs.VALUE < lhs.VALUE (triangular)
また
SELF self1
INNER JOIN SELF self2
ON self2.key <> self1.key
AND self1.type = self2.type
(self cross と antijoin を使用して、自分以外のすべての類似したファミリ メンバーを検索します。self1 と self2 は同じセットであり、結果は適切なサブセットです)
チュートリアルの最初の数分間は、キーの結合に固執しても問題ないかもしれませんが、これは、結合とは何かを学習するための不十分なパスにつながる可能性があります。これがあなたが見つけたものだと思います。
ベン図が JOIN を一般的にこのように表すことができるというこの考えは、なくなる必要があります。
正しい結合の場合、構文が混乱する可能性がありますが、そうです。「TableA RIGHT JOIN TableB」と言うとき、実際には、TableB が参照しているメイン テーブルであり、TableA は一致するレコードがある場所にぶら下がっているだけです。これは、TableA が最初にリストされているため、TableB が実際にはクエリでより重要なテーブルであっても、脳が自動的により高い優先順位を割り当てるため、クエリでは奇妙に解釈されます。このため、実際のコードで右結合を目にすることはめったにありません。
そこで、A と B の代わりに、追跡しやすい 2 つのものを考えてみましょう。人の情報、ShoeSize と IQ の 2 つのテーブルがあるとします。一部の人にはShoeSize情報があり、一部の人にはIQ情報があります。そして、参加できる両方のテーブルに PersonID があります。
右上から時計回りに（これは、より複雑で不自然なケースのいくつかから始まります）：
結合を行う場合、2 つのテーブルが完全に一致しない可能性があります。具体的には、B のどの行とも一致しない A の行がいくつかある場合や、B の単一の行と一致する A の行が重複している場合や、その逆の場合があります。
これが発生した場合、次の選択肢があります。
中央の左と右は技術的には結合ですが、無意味です。おそらくもっと効率的に書くことができますSELECT <select_list> FROM TableA A WHERE A.Key NOT IN (SELECT B.Key FROM TableB B)（またはその逆）。
あなたの混乱に対する直接的な答えとして、RIGHT JOIN「次の式がこのクエリの焦点です」と言います。右下はかなり奇妙で、あなたがそれを望む理由がわかりません。NULL反対側のテーブルのすべての列で 's と一緒に混合された、2 つの外側の中央のクエリからの結果を返します。