L'idea generale
Si prega di consultare la risposta di Martin Smith per una migliore spiegazione e spiegazione dei diversi join, comprese e in particolare le differenze tra FULL OUTER JOIN, RIGHT OUTER JOINe LEFT OUTER JOIN.
Queste due tabelle costituiscono una base per la rappresentazione delle JOINseguenti:
CROSS JOIN
SELECT *
FROM citizen
CROSS JOIN postalcode
Il risultato saranno i prodotti cartesiani di tutte le combinazioni. Nessuna JOINcondizione richiesta:
UNIONE INTERNA
INNER JOIN è uguale al semplice: JOIN
SELECT *
FROM citizen c
JOIN postalcode p ON c.postal = p.postal
Il risultato saranno combinazioni che soddisfano la JOINcondizione richiesta :
SINISTRA ESTERNO UNISCITI
LEFT OUTER JOIN equivale a LEFT JOIN
SELECT *
FROM citizen c
LEFT JOIN postalcode p ON c.postal = p.postal
Il risultato sarà tutto, citizenanche se non ci sono partite in postalcode. Ancora una volta JOINè richiesta una condizione:
Dati per giocare
Tutti gli esempi sono stati eseguiti su un Oracle 18c. Sono disponibili su dbfiddle.uk, che è anche il luogo di provenienza degli screenshot dei tavoli.
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;
Confini confusi quando si gioca con JOINeWHERE
CROSS JOIN
CROSS JOINrisultante in righe come L'idea generale / INNER JOIN:
SELECT *
FROM citizen c
CROSS JOIN postalcode p
WHERE c.postal = p.postal -- < -- The WHERE condition is limiting the resulting rows
Utilizzare CROSS JOINper ottenere il risultato di un LEFT OUTER JOINrichiede trucchi come l'aggiunta in una NULLriga. È stato omesso.
UNIONE INTERNA
INNER JOINdiventa un prodotto cartesiano. È lo stesso di The General Idea / CROSS JOIN:
SELECT *
FROM citizen c
JOIN postalcode p ON 1 = 1 -- < -- The ON condition makes it a CROSS JOIN
È qui che il join interno può davvero essere visto come il join incrociato con risultati che non corrispondono alla condizione rimossa. Qui nessuna delle righe risultanti viene rimossa.
Usare INNER JOINper ottenere il risultato di un LEFT OUTER JOINrichiede anche dei trucchi. È stato omesso.
SINISTRA ESTERNO UNISCITI
LEFT JOINrisulta nelle righe come L'idea generale / CROSS JOIN:
SELECT *
FROM citizen c
LEFT JOIN postalcode p ON 1 = 1 -- < -- The ON condition makes it a CROSS JOIN
LEFT JOINrisulta nelle righe come L'idea generale / 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
I problemi con il diagramma di Venn
Una ricerca di immagini su "sql join cross inner external" mostrerà una moltitudine di diagrammi di Venn. Avevo una copia stampata di uno sulla mia scrivania. Ma ci sono problemi con la rappresentazione.
Il diagramma di Venn è eccellente per la teoria degli insiemi, in cui un elemento può trovarsi in uno o entrambi gli insiemi. Ma per i database, un elemento in un "set" mi sembra una riga in una tabella e quindi non è presente in nessuna altra tabella. Non esiste una riga presente in più tabelle. Una riga è unica per la tabella.
I self join sono un caso angolare in cui ogni elemento è in effetti lo stesso in entrambi i set. Ma non è ancora libero da nessuno dei problemi di seguito.
L'insieme Arappresenta l'insieme a sinistra (la citizentabella) e l'insieme Bè l'insieme a destra (la postalcodetabella) nella discussione di seguito.
CROSS JOIN
Ogni elemento di entrambi gli insiemi è abbinato a ogni elemento dell'altro insieme, il che significa che abbiamo bisogno di Aquantità di ogni Belemento e Bquantità di ogni Aelemento per rappresentare correttamente questo prodotto cartesiano. La teoria degli insiemi non è fatta per più elementi identici in un insieme, quindi trovo che i diagrammi di Venn rappresentino correttamente impraticabile / impossibile. Non sembra che si UNIONadatti affatto.
Le righe sono distinte. Sono UNION7 righe in totale. Ma sono incompatibili per un SQLset di risultati comune . E non è affatto così che CROSS JOINfunziona:
Cercando di rappresentarlo in questo modo:
..ma ora sembra proprio come una INTERSECTION, che è certamente non è . Inoltre non vi è alcun elemento nel fatto INTERSECTIONche si trova effettivamente in nessuno dei due set distinti. Tuttavia, assomiglia molto ai risultati della ricerca simili a questo:
Per riferimento un risultato ricercabile per CROSS JOINs può essere visto su Tutorialgateway . Il INTERSECTION, proprio come questo, è vuoto.
UNIONE INTERNA
Il valore di un elemento dipende dalla JOINcondizione. È possibile rappresentarlo a condizione che ogni riga diventi unica per quella condizione. Il significato id=xè vero solo per una riga. Una volta che una riga nella tabella A( citizen) corrisponde a più righe nella tabella B( postalcode) nella JOINcondizione, il risultato presenta gli stessi problemi del CROSS JOIN: La riga deve essere rappresentata più volte e la teoria degli insiemi non è fatta per questo. Nella condizione di unicità, il diagramma potrebbe funzionare, ma tieni presente che la JOINcondizione determina il posizionamento di un elemento nel diagramma. Osservando solo i valori della JOINcondizione con il resto della riga, giusto per la corsa:
Questa rappresentazione cade completamente a pezzi quando si usa un INNER JOINcon una ON 1 = 1condizione che lo trasforma in a CROSS JOIN.
Con un self- JOIN, le righe sono in realtà elementi identici in entrambe le tabelle, ma rappresentano le tabelle come entrambe Ae Bnon sono molto adatte. Ad esempio, una JOINcondizione autonoma comune che fa in modo che un elemento Acorrisponda a un elemento diverso in B è ON A.parent = B.child, facendo la corrispondenza da Aa Belementi separati. Dagli esempi che sarebbe SQLsimile a questo:
SELECT *
FROM citizen c1
JOIN citizen c2 ON c1.id = c2.leader
Significa che Smith è il leader di Green e Jensen.
ISCRIVITI ESTERNO
Ancora una volta i problemi iniziano quando una riga ha più corrispondenze con le righe nell'altra tabella. Ciò è ulteriormente complicato perché si OUTER JOINpuò pensare che corrisponda all'insieme vuoto. Ma nella teoria degli insiemi l'unione di qualsiasi insieme Ce un insieme vuoto è sempre giusta C. Il set vuoto non aggiunge nulla. La rappresentazione di questo di LEFT OUTER JOINsolito mostra solo tutto Aper illustrare che le righe Asono selezionate indipendentemente dal fatto che ci sia o meno una corrispondenza B. Gli "elementi corrispondenti" presentano tuttavia gli stessi problemi dell'illustrazione sopra. Dipendono dalla condizione. E il set vuoto sembra aver vagato per A:
Clausola WHERE - ha senso
Trovare tutte le righe da a CROSS JOINcon Smith e il codice postale sulla Luna:
SELECT *
FROM citizen c
CROSS JOIN postalcode p
WHERE c.name = 'Smith'
AND p.area = 'Moon';
Ora il diagramma di Venn non viene utilizzato per riflettere il JOIN. È usato solo per la WHEREclausola:
..e questo ha senso.
Quando INTERSECT e UNION hanno senso
INTERSECT
Come spiegato an INNER JOINnon è proprio un INTERSECT. Tuttavia, INTERSECTè possibile utilizzare s sui risultati di query separate. Qui un diagramma di Venn ha senso, perché gli elementi delle query separate sono in realtà righe che appartengono solo a uno dei risultati o entrambi. Intersect ovviamente restituirà risultati solo se la riga è presente in entrambe le query. Ciò SQLcomporterà la stessa riga di quella sopra WHEREe anche il diagramma di Venn sarà lo stesso:
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';
UNIONE
An OUTER JOINnon è un UNION. Tuttavia, UNIONlavorare nelle stesse condizioni di INTERSECT, risultando in un ritorno di tutti i risultati combinando entrambi i 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';
che equivale a:
SELECT *
FROM citizen c
CROSS JOIN postalcode p
WHERE c.name = 'Smith'
OR p.area = 'Moon';
..e dà il risultato:
Anche qui un diagramma di Venn ha senso:
Quando non si applica
Una nota importante è che funzionano solo quando la struttura dei risultati dei due SELECT è la stessa, consentendo un confronto o unione. I risultati di questi due non consentiranno che:
SELECT *
FROM citizen
WHERE name = 'Smith'
SELECT *
FROM postalcode
WHERE area = 'Moon';
.. provare a combinare i risultati con UNIONdà a
ORA-01790: expression must have same datatype as corresponding expression
Per ulteriore interesse, leggi Dì NO ai diagrammi di Venn quando spieghi i JOIN e i join sql come diagramma di Venn . Entrambi coprono anche EXCEPT.
