Wie andere bereits erwähnt haben, sind LEFT OUTER JOIN und RIGHT OUTER JOIN genau die gleichen Operationen, außer dass ihre Argumente umgekehrt sind. Ihre Frage ist wie die Frage, ob es besser ist, a < b oder b > a zu schreiben. Sie sind die gleichen - es ist nur eine Frage der Präferenz.
Nachdem ich das gesagt habe, finde ich, dass die meisten Leute mit LEFT JOIN vertrauter sind und sie konsistent in ihrer SQL benutzen. Manche Leute finden es sogar ziemlich schwierig zu lesen, wenn sich plötzlich eine RIGHT JOIN in der Mitte einer Anfrage befindet, und sie veranlasst sie zu stoppen und zu denken, was es bedeutet. Daher würde ich vorschlagen, dass bei gleicher Wahl zwischen den beiden Optionen LEFT JOIN verwendet werden sollte. Durch die Konsistenz wird es anderen Entwicklern einfacher, Ihr SQL zu verstehen.
Diese sind gleich, nur eine Frage der Präferenz und Lesbarkeit. Ich nehme an, es sind die gleichen Tabellen?
Linke äußere Verknüpfung
Das Ergebnis eines linken äußeren Joins (oder einfach linken Joins) für Tabelle A und B enthält immer alle Datensätze der "linken" Tabelle (A), selbst wenn die Join-Bedingung keinen übereinstimmenden Datensatz in der " rechts "Tabelle (B). Das heißt, wenn die ON-Klausel 0 (null) Datensätze in B entspricht, gibt der Join immer noch eine Zeile im Ergebnis zurück - aber mit NULL in jeder Spalte von B. Dies bedeutet, dass ein linker äußerer Join alle Werte zurückgibt aus der linken Tabelle, plus übereinstimmende Werte aus der rechten Tabelle (oder NULL, falls kein passendes Join-Prädikat vorhanden ist)
Rechte äußere Verknüpfung
Ein rechter äußerer Join (oder rechter Join) ähnelt stark einem linken äußeren Join, außer bei der umgekehrten Behandlung der Tabellen . Jede Zeile aus der "richtigen" Tabelle (B) erscheint mindestens einmal in der verbundenen Tabelle. Wenn keine passende Zeile aus der "linken" Tabelle (A) existiert, erscheint NULL in Spalten von A für die Datensätze, die keine Übereinstimmung in B haben. Ein rechter äußerer Join gibt alle Werte aus der rechten Tabelle und übereinstimmenden Werten aus der linken Tabelle zurück (NULL, falls kein übereinstimmendes Join-Prädikat vorhanden ist).
Die Entwickler der SQL-Sprache waren der Ansicht, dass die Durchsetzung der Links-zu-Rechts-Priorität der Joins eine unnötige Einschränkung der Sprache darstellte (leider waren sie bei der Reihenfolge der Spalten nicht gleich!)
Es scheint eine starke Präferenz für LEFT OUTER hier bei Stackoverflow zu geben, in dem Ausmaß, in dem Folk die ganze Verbindung ändert, nur um LEFT verwenden zu können (wir hatten eine hier gerade gestern).
Angenommen, Sie haben ursprünglich in Ihre Abfrage Table_2 INNER JOIN Table_1 geschrieben, bevor Sie erkannt haben, dass Sie tatsächlich einen äußeren Join benötigen, der alle Zeilen von Table_1 enthält. Es wäre viel einfacher, INNER in RIGHT OUTER zu ändern, als die gesamte Verknüpfung zu ändern, um LEFT OUTER verwenden zu können. Einfach ist hier gut, weil es weniger invasiv ist und daher weniger Gefahr besteht, dass die Absicht der Abfrage unbeabsichtigt geändert wird.
Um ein anderes ähnliches Beispiel zu verwenden, betrachten Sie den relationalen Operator halb beitreten ; Als Teil der relationalen Algebra kann eine Technologie ohne sie nicht als relational vollständig betrachtet werden. Obwohl Standard SQL über ein Semi-Join-Prädikat MATCH verfügt, ist es nicht weit verbreitet. Die meisten SQL-Produkte unterstützen jedoch verschiedene Problemumgehungen. Der am häufigsten verwendete Ansatz in Stackoverflow scheint darin zu bestehen, INNER JOIN mit DISTINCT in der SELECT -Klausel zu verwenden und Attribute aus der verbundenen Tabelle wegzulassen. Dies wird dicht gefolgt von WHERE table_1.ID IN (SELECT ID FROM Table_2) . Nächst populärster ist WHERE EXISTS (SELECT * FROM Table_2 WHERE table_1.ID = table_1.ID) .
Der Punkt ist, dass alle oben genannten Semi-Joins sehr häufig in der Wildnis vorkommen. Obwohl ich persönlich EXISTS verwenden möchte (obwohl es merkwürdigerweise näher am relationalen Kalkül liegt), muss ich immer noch in der Lage sein, die anderen als Semi-Joins zu identifizieren. Interessanterweise kann der am häufigsten verwendete Ansatz ( INNER JOIN plus DISTINCT plus Nichtprojektion) am schwierigsten zu identifizieren sein!
Refactoring-Code zum alleinigen Zweck der Anpassung an den persönlichen Stil ist zu Recht verpönt: Kosten für unnötigen Aufwand, Erhöhung des Risikos, Implikation für die Quellcode-Kontrolle usw. Das Erkennen und Respektieren anderer Präferenzen ist eine wichtige Fähigkeit: Wenn Sie sich selbst finden Refactoring einmal nur um es zu verstehen, werden Sie sich benachteiligen.
Natürlich ist die "korrekte" Antwort, relational gesehen, die äußere Verbindung vollständig zu vermeiden. Im relationalen Modell gibt es keine Null, und Outer-Joins sind ausdrücklich darauf ausgelegt, Nullen zu erzeugen.