Die allgemeine Idee
Bitte beachten Sie die Antwort von Martin Smith für eine bessere illustations und Erläuterungen zu den verschiedenen beitritt, auch und vor allem Unterschiede zwischen FULL OUTER JOIN, RIGHT OUTER JOINund LEFT OUTER JOIN.
Diese beiden Tabellen bilden eine Grundlage für die Darstellung der folgenden JOINs:
CROSS JOIN
SELECT *
FROM citizen
CROSS JOIN postalcode
Das Ergebnis sind die kartesischen Produkte aller Kombinationen. Keine JOINBedingung erforderlich:
INNER JOIN
INNER JOIN ist das gleiche wie einfach: JOIN
SELECT *
FROM citizen c
JOIN postalcode p ON c.postal = p.postal
Das Ergebnis sind Kombinationen, die die erforderliche JOINBedingung erfüllen:
LINKE ÄUSSERE VERBINDUNG
LEFT OUTER JOIN ist das gleiche wie LEFT JOIN
SELECT *
FROM citizen c
LEFT JOIN postalcode p ON c.postal = p.postal
Das Ergebnis wird alles sein, citizenauch wenn es keine Übereinstimmungen gibt postalcode. Wieder ist eine JOINBedingung erforderlich:
Daten zum Spielen
Alle Beispiele wurden auf einem Oracle 18c ausgeführt. Sie sind auf dbfiddle.uk erhältlich. Dort stammen auch Screenshots von Tabellen.
CREATE TABLE citizen (id NUMBER,
name VARCHAR2(20),
postal NUMBER, -- <-- could do with a redesign to postalcode.id instead.
leader NUMBER);
CREATE TABLE postalcode (id NUMBER,
postal NUMBER,
city VARCHAR2(20),
area VARCHAR2(20));
INSERT INTO citizen (id, name, postal, leader)
SELECT 1, 'Smith', 2200, null FROM DUAL
UNION SELECT 2, 'Green', 31006, 1 FROM DUAL
UNION SELECT 3, 'Jensen', 623, 1 FROM DUAL;
INSERT INTO postalcode (id, postal, city, area)
SELECT 1, 2200, 'BigCity', 'Geancy' FROM DUAL
UNION SELECT 2, 31006, 'SmallTown', 'Snizkim' FROM DUAL
UNION SELECT 3, 31006, 'Settlement', 'Moon' FROM DUAL -- <-- Uuh-uhh.
UNION SELECT 4, 78567390, 'LookoutTowerX89', 'Space' FROM DUAL;
Verschwommene Grenzen beim Spielen mit JOINundWHERE
CROSS JOIN
CROSS JOINDaraus resultieren Zeilen wie The General Idea / INNER JOIN:
SELECT *
FROM citizen c
CROSS JOIN postalcode p
WHERE c.postal = p.postal -- < -- The WHERE condition is limiting the resulting rows
Die Verwendung CROSS JOIN, um das Ergebnis von a zu erhalten, LEFT OUTER JOINerfordert Tricks wie das Hinzufügen in einer NULLReihe. Es ist weggelassen.
INNER JOIN
INNER JOINwird ein kartesisches Produkt. Es ist das gleiche wie The General Idea / CROSS JOIN:
SELECT *
FROM citizen c
JOIN postalcode p ON 1 = 1 -- < -- The ON condition makes it a CROSS JOIN
Hier kann der innere Join wirklich als Cross-Join angesehen werden, dessen Ergebnisse nicht mit der entfernten Bedingung übereinstimmen. Hier wird keine der resultierenden Zeilen entfernt.
Mit INNER JOINdem Ergebnis erhalten einer LEFT OUTER JOINauch Tricks erfordert. Es ist weggelassen.
LINKE ÄUSSERE VERBINDUNG
LEFT JOINergibt in Zeilen als The General Idea / CROSS JOIN:
SELECT *
FROM citizen c
LEFT JOIN postalcode p ON 1 = 1 -- < -- The ON condition makes it a CROSS JOIN
LEFT JOINergibt in Zeilen als The General Idea / INNER JOIN:
SELECT *
FROM citizen c
LEFT JOIN postalcode p ON c.postal = p.postal
WHERE p.postal IS NOT NULL -- < -- removed the row where there's no mathcing result from postalcode
Die Probleme mit dem Venn-Diagramm
Eine Bild-Internetsuche auf "SQL Join Cross Inner Outer" zeigt eine Vielzahl von Venn-Diagrammen. Früher hatte ich eine gedruckte Ausgabe auf meinem Schreibtisch. Es gibt jedoch Probleme mit der Darstellung.
Venn-Diagramme eignen sich hervorragend für die Mengenlehre, bei der sich ein Element in einer oder beiden Mengen befinden kann. Bei Datenbanken scheint mir ein Element in einer "Menge" eine Zeile in einer Tabelle zu sein und daher auch in keiner anderen Tabelle vorhanden zu sein. In mehreren Tabellen ist keine Zeile vorhanden. Eine Zeile ist für die Tabelle eindeutig.
Self-Joins sind ein Eckfall, in dem jedes Element in beiden Mengen tatsächlich gleich ist. Aber es ist immer noch nicht frei von den folgenden Problemen.
Das Set Arepräsentiert das Set links (die citizenTabelle) und das Set Bist das Set rechts (die postalcodeTabelle) in der folgenden Diskussion.
CROSS JOIN
Jedes Element in beiden Mengen wird mit jedem Element in der anderen Menge abgeglichen, was bedeutet, dass wir die AMenge aller BElemente und die BMenge aller AElemente benötigen , um dieses kartesische Produkt richtig darzustellen. Die Mengenlehre ist nicht für mehrere identische Elemente in einer Menge gemacht, daher finde ich Venn-Diagramme, um sie richtig darzustellen, unpraktisch / unmöglich. Es scheint überhaupt nicht zu UNIONpassen.
Die Zeilen sind unterschiedlich. Das UNIONsind insgesamt 7 Zeilen. Sie sind jedoch für eine gemeinsame SQLErgebnismenge nicht kompatibel . Und so funktioniert ein CROSS JOINüberhaupt nicht:
Der Versuch, es so darzustellen:
..aber jetzt sieht es einfach aus wie ein INTERSECTION, was es sicher nicht ist . Darüber hinaus gibt es kein Element in dem INTERSECTION, das sich tatsächlich in einer der beiden unterschiedlichen Mengen befindet. Es sieht jedoch den folgenden durchsuchbaren Ergebnissen sehr ähnlich:
Als Referenz kann ein durchsuchbares Ergebnis für CROSS JOINs bei Tutorialgateway angezeigt werden . Das INTERSECTIONist genau wie dieses leer.
INNER JOIN
Der Wert eines Elements hängt von der JOINBedingung ab. Es ist möglich, dies unter der Bedingung darzustellen, dass jede Zeile für diese Bedingung eindeutig wird. Die Bedeutung id=xgilt nur für eine Zeile. Sobald eine Zeile in der Tabelle A( citizen) mehrere Zeilen in der Tabelle übereinstimmt B( postalcode) unter der JOINBedingung, hat das Ergebnis die gleichen Probleme wie die CROSS JOIN: Die Zeile mehrfach dargestellt werden muss, und die Mengenlehre ist für das nicht wirklich gemacht. Unter der Bedingung der Eindeutigkeit könnte das Diagramm zwar funktionieren, bedenken Sie jedoch, dass die JOINBedingung die Platzierung eines Elements im Diagramm bestimmt. Betrachten Sie nur die Werte der JOINBedingung mit dem Rest der Reihe gerade für die Fahrt:
Diese Darstellung fällt vollständig auseinander, wenn ein INNER JOINmit einer ON 1 = 1Bedingung verwendet wird, die es zu einem macht CROSS JOIN.
Bei einem Selbst JOINsind die Zeilen tatsächlich identische Elemente in beiden Tabellen, stellen jedoch die Tabellen als beide dar Aund Bsind nicht sehr geeignet. Eine übliche Selbstbedingung JOIN, die bewirkt , dass ein Element Amit einem anderen Element in B übereinstimmt, ist beispielsweise ON A.parent = B.child, dass die Übereinstimmung von Abis Bzu separaten Elementen erfolgt. Aus den Beispielen, die so SQLaussehen würden:
SELECT *
FROM citizen c1
JOIN citizen c2 ON c1.id = c2.leader
Das heißt, Smith ist der Anführer von Green und Jensen.
OUTER JOIN
Wieder beginnen die Probleme, wenn eine Zeile mehrere Übereinstimmungen mit Zeilen in der anderen Tabelle aufweist. Dies ist weiter kompliziert, da dies OUTER JOINjedoch so sein kann, dass es mit dem leeren Satz übereinstimmt. Aber in der Mengenlehre ist die Vereinigung einer Menge Cund einer leeren Menge immer gerecht C. Der leere Satz fügt nichts hinzu. Die Darstellung LEFT OUTER JOINzeigt normalerweise nur alle, um Azu veranschaulichen, dass Zeilen in Aausgewählt sind, unabhängig davon, ob eine Übereinstimmung vorliegt oder nicht B. Die "passenden Elemente" haben jedoch die gleichen Probleme wie die obige Abbildung. Sie hängen von der Bedingung ab. Und das leere Set scheint hinübergegangen zu sein zu A:
WHERE-Klausel - sinnvoll
Finden aller Zeilen von a CROSS JOINmit Smith und Postleitzahl auf dem Mond:
SELECT *
FROM citizen c
CROSS JOIN postalcode p
WHERE c.name = 'Smith'
AND p.area = 'Moon';
Jetzt wird das Venn-Diagramm nicht mehr verwendet, um das wiederzugeben JOIN. Es wird nur für die WHEREKlausel verwendet:
..und das macht Sinn.
Wenn INTERSECT und UNION Sinn machen
SICH SCHNEIDEN
Wie erklärt INNER JOINist ein nicht wirklich ein INTERSECT. Allerdings INTERSECTkann s auf den Ergebnissen der separaten Abfragen verwendet werden. Hier ist ein Venn-Diagramm sinnvoll, da die Elemente aus den einzelnen Abfragen tatsächlich Zeilen sind, die entweder nur zu einem der Ergebnisse oder zu beiden gehören. Intersect gibt offensichtlich nur Ergebnisse zurück, wenn die Zeile in beiden Abfragen vorhanden ist. Dies SQLführt zu derselben Zeile wie oben WHERE, und das Venn-Diagramm ist auch dasselbe:
SELECT *
FROM citizen c
CROSS JOIN postalcode p
WHERE c.name = 'Smith'
INTERSECT
SELECT *
FROM citizen c
CROSS JOIN postalcode p
WHERE p.area = 'Moon';
UNION
An OUTER JOINist nicht a UNION. Doch UNIONunter den gleichen Bedingungen wie arbeiten INTERSECT, in einer Rückkehr aller Ergebnisse resultierend beide kombiniert SELECTs:
SELECT *
FROM citizen c
CROSS JOIN postalcode p
WHERE c.name = 'Smith'
UNION
SELECT *
FROM citizen c
CROSS JOIN postalcode p
WHERE p.area = 'Moon';
was äquivalent ist zu:
SELECT *
FROM citizen c
CROSS JOIN postalcode p
WHERE c.name = 'Smith'
OR p.area = 'Moon';
..und gibt das Ergebnis:
Auch hier macht ein Venn-Diagramm Sinn:
Wenn es nicht zutrifft
Ein wichtiger Hinweis ist, dass diese nur funktionieren, wenn die Struktur der Ergebnisse der beiden SELECTs gleich ist, was einen Vergleich oder eine Vereinigung ermöglicht. Die Ergebnisse dieser beiden werden dies nicht ermöglichen:
SELECT *
FROM citizen
WHERE name = 'Smith'
SELECT *
FROM postalcode
WHERE area = 'Moon';
..versucht, die Ergebnisse mit zu kombinieren, UNIONergibt a
ORA-01790: expression must have same datatype as corresponding expression
Für weiteres Interesse lesen Sie NEIN zu Venn-Diagrammen, wenn Sie JOINs und SQL-Joins als Venn-Diagramm erläutern . Beide decken auch ab EXCEPT.
