L'idée générale
Veuillez consulter la réponse de Martin Smith pour de meilleures illustrations et explications des différentes jointures, y compris et surtout les différences entre FULL OUTER JOIN, RIGHT OUTER JOINet LEFT OUTER JOIN.
Ces deux tableaux constituent une base pour la représentation des JOINs ci-dessous:
CROSS JOIN
SELECT *
FROM citizen
CROSS JOIN postalcode
Le résultat sera les produits cartésiens de toutes les combinaisons. Aucune JOINcondition requise:
JOINTURE INTERNE
INNER JOIN est la même chose que simplement: JOIN
SELECT *
FROM citizen c
JOIN postalcode p ON c.postal = p.postal
Le résultat sera des combinaisons qui satisfont à la JOINcondition requise :
JOINTURE EXTERNE GAUCHE
LEFT OUTER JOIN est le même que LEFT JOIN
SELECT *
FROM citizen c
LEFT JOIN postalcode p ON c.postal = p.postal
Le résultat sera tout, citizenmême s'il n'y a pas de correspondance postalcode. Encore une fois, une JOINcondition est requise:
Données pour jouer
Tous les exemples ont été exécutés sur un Oracle 18c. Ils sont disponibles sur dbfiddle.uk, d' où proviennent également les captures d'écran des tableaux.
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;
Limites floues lors de la lecture avec JOINetWHERE
CROSS JOIN
CROSS JOINrésultant en lignes comme l'idée générale / INNER JOIN:
SELECT *
FROM citizen c
CROSS JOIN postalcode p
WHERE c.postal = p.postal -- < -- The WHERE condition is limiting the resulting rows
L'utilisation CROSS JOINpour obtenir le résultat d'un LEFT OUTER JOINrequiert des astuces comme l'ajout NULLconsécutif. C'est omis.
JOINTURE INTERNE
INNER JOINdevient un produit cartésien. C'est la même chose que The General Idea / CROSS JOIN:
SELECT *
FROM citizen c
JOIN postalcode p ON 1 = 1 -- < -- The ON condition makes it a CROSS JOIN
C'est là que la jointure interne peut vraiment être vue comme la jointure croisée avec des résultats ne correspondant pas à la condition supprimée. Ici, aucune des lignes résultantes n'est supprimée.
Utiliser INNER JOINpour obtenir le résultat d'un LEFT OUTER JOINnécessite également des astuces. C'est omis.
JOINTURE EXTERNE GAUCHE
LEFT JOINrésulte en lignes comme l'idée générale / CROSS JOIN:
SELECT *
FROM citizen c
LEFT JOIN postalcode p ON 1 = 1 -- < -- The ON condition makes it a CROSS JOIN
LEFT JOINrésulte en lignes comme l'idée générale / 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
Les problèmes avec le diagramme de Venn
Une recherche d'image sur Internet sur "sql join cross inner inner" montrera une multitude de diagrammes de Venn. J'en avais une copie imprimée sur mon bureau. Mais il y a des problèmes avec la représentation.
Le diagramme de Venn est excellent pour la théorie des ensembles, où un élément peut être dans l'un ou les deux ensembles. Mais pour les bases de données, un élément dans un "ensemble" me semble être une ligne dans une table, et donc pas également présent dans d'autres tables. Il n'y a rien de tel qu'une ligne présente dans plusieurs tables. Une ligne est unique à la table.
Les auto-jointures sont un cas d'angle où chaque élément est en fait le même dans les deux ensembles. Mais ce n'est toujours pas exempt des problèmes ci-dessous.
L'ensemble Areprésente l'ensemble à gauche (le citizentableau) et l'ensemble Best l'ensemble à droite (le postalcodetableau) dans la discussion ci-dessous.
CROSS JOIN
Chaque élément des deux ensembles correspond à chaque élément de l'autre ensemble, ce qui signifie que nous avons besoin de la Aquantité de tous les Béléments et de la Bquantité de tous les Aéléments pour représenter correctement ce produit cartésien. La théorie des ensembles n'est pas faite pour plusieurs éléments identiques dans un ensemble, donc je trouve que les diagrammes de Venn pour le représenter correctement sont peu pratiques / impossibles. Il ne semble pas queUNION convenir.
Les rangées sont distinctes. Il UNIONs'agit d'un total de 7 lignes. Mais ils sont incompatibles pour un SQLensemble de résultats commun . Et ce n'est pas du tout ainsi que CROSS JOINfonctionne:
Essayer de le représenter comme ceci:
..mais maintenant ça ressemble à un INTERSECTION, ce qui n'est certainement pas le cas . De plus, il n'y a aucun élément dans INTERSECTIONqui se trouve réellement dans l'un des deux ensembles distincts. Cependant, cela ressemble beaucoup aux résultats consultables similaires à ceci:
Pour référence, un résultat de recherche pour CROSS JOINs peut être vu sur Tutorialgateway . Le INTERSECTION, tout comme celui-ci, est vide.
JOINTURE INTERNE
La valeur d'un élément dépend de la JOINcondition. Il est possible de représenter cela sous la condition que chaque ligne devienne unique à cette condition. La signification id=xn'est vraie que pour une ligne. Une fois qu'une ligne de table A( citizen) correspond à plusieurs lignes de table B( postalcode) sous la JOINcondition, le résultat présente les mêmes problèmes que CROSS JOIN: La ligne doit être représentée plusieurs fois, et la théorie des ensembles n'est pas vraiment faite pour cela. Sous la condition d'unicité, le diagramme peut cependant fonctionner, mais gardez à l'esprit que la JOINcondition détermine le placement d'un élément dans le diagramme. En regardant uniquement les valeurs de la JOINcondition avec le reste de la ligne juste pour la balade:
Cette représentation s'effondre complètement lors de l'utilisation d'un INNER JOINavec une ON 1 = 1condition qui en fait un CROSS JOIN.
Avec un self- JOIN, les lignes sont en fait des éléments identitaires dans les deux tables, mais représentant les tables comme les deux Aet Bn'est pas très approprié. Par exemple , un auto commun JOINcondition qui rend un élément Aà faire correspondre un autre élément B est ON A.parent = B.child, ce qui rend la correspondance d' Aà Bdes éléments séparés. D'après les exemples qui SQLressembleraient à ceci:
SELECT *
FROM citizen c1
JOIN citizen c2 ON c1.id = c2.leader
Ce qui signifie que Smith est le leader de Green et de Jensen.
JOINT EXTERIEUR
Encore une fois, les problèmes commencent lorsqu'une ligne a plusieurs correspondances avec les lignes de l'autre table. Ceci est encore plus compliqué parce que le OUTER JOINpeut correspondre à l'ensemble vide. Mais dans la théorie des ensembles, l'union d'un ensemble Cet d'un ensemble vide est toujours juste C. L'ensemble vide n'ajoute rien. La représentation de ceci LEFT OUTER JOINmontre généralement tout Apour illustrer que les lignes Asont sélectionnées indépendamment de la présence ou non d'une correspondance B. Les "éléments correspondants" ont cependant les mêmes problèmes que l'illustration ci-dessus. Ils dépendent de la condition. Et l'ensemble vide semble avoir erré vers A:
Clause WHERE - sens
Trouver toutes les lignes d'un CROSS JOINavec Smith et le code postal sur la Lune:
SELECT *
FROM citizen c
CROSS JOIN postalcode p
WHERE c.name = 'Smith'
AND p.area = 'Moon';
Maintenant, le diagramme de Venn n'est pas utilisé pour refléter le JOIN. Il est utilisé uniquement pour la WHEREclause:
..et cela a du sens.
Quand INTERSECT et UNION ont du sens
COUPER
Comme expliqué, ce INNER JOINn'est pas vraiment un INTERSECT. Cependant, INTERSECTs peut être utilisé sur les résultats de requêtes distinctes. Ici, un diagramme de Venn est logique, car les éléments des requêtes distinctes sont en fait des lignes qui appartiennent à l'un des résultats ou aux deux. Intersect ne retournera évidemment que les résultats là où la ligne est présente dans les deux requêtes. Cela SQLse traduira par la même ligne que celle ci-dessus WHERE, et le diagramme de Venn sera également le même:
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';
SYNDICAT
Un OUTER JOINn'est pas un UNION. Cependant, UNIONtravaillez dans les mêmes conditions que INTERSECT, ce qui entraîne un retour de tous les résultats combinant les deux 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';
ce qui équivaut à:
SELECT *
FROM citizen c
CROSS JOIN postalcode p
WHERE c.name = 'Smith'
OR p.area = 'Moon';
..et donne le résultat:
Ici aussi, un diagramme de Venn est logique:
Quand cela ne s'applique pas
Une note importante est que ceux-ci ne fonctionnent que lorsque la structure des résultats des deux SELECT est la même, permettant une comparaison ou une union. Les résultats de ces deux ne permettront pas que:
SELECT *
FROM citizen
WHERE name = 'Smith'
SELECT *
FROM postalcode
WHERE area = 'Moon';
..essayer de combiner les résultats avec UNIONdonne un
ORA-01790: expression must have same datatype as corresponding expression
Pour plus d'intérêt, lisez Dire NON aux diagrammes Venn lors de l'explication des jointures et des jointures sql en tant que diagramme venn . Les deux couvrent également EXCEPT.
