A idéia geral
Por favor, veja a resposta de Martin Smith para obter melhores ilustrações e explicações sobre as diferentes junções, incluindo e especialmente as diferenças entre FULL OUTER JOIN, RIGHT OUTER JOINe LEFT OUTER JOIN.
Essas duas tabelas formam uma base para a representação dos JOINs abaixo:
CROSS JOIN
SELECT *
FROM citizen
CROSS JOIN postalcode
O resultado serão os produtos cartesianos de todas as combinações. Nenhuma JOINcondição necessária:
JUNÇÃO INTERNA
INNER JOIN é o mesmo que simplesmente: JOIN
SELECT *
FROM citizen c
JOIN postalcode p ON c.postal = p.postal
O resultado serão combinações que satisfazem a JOINcondição necessária :
JUNTA EXTERNA ESQUERDA
LEFT OUTER JOIN é o mesmo que LEFT JOIN
SELECT *
FROM citizen c
LEFT JOIN postalcode p ON c.postal = p.postal
O resultado será tudo, citizenmesmo que não haja correspondências postalcode. Novamente, uma JOINcondição é necessária:
Dados para jogar
Todos os exemplos foram executados em um Oracle 18c. Eles estão disponíveis no dbfiddle.uk, que também é de onde vieram as capturas de tela das tabelas.
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 desfocados ao brincar com JOINeWHERE
CROSS JOIN
CROSS JOINresultando em linhas como A idéia geral / INNER JOIN:
SELECT *
FROM citizen c
CROSS JOIN postalcode p
WHERE c.postal = p.postal -- < -- The WHERE condition is limiting the resulting rows
Usar CROSS JOINpara obter o resultado de a LEFT OUTER JOINrequer truques como adicionar em uma NULLlinha. Está omitido.
JUNÇÃO INTERNA
INNER JOINtorna-se um produto cartesiano. É o mesmo que The General Idea / CROSS JOIN:
SELECT *
FROM citizen c
JOIN postalcode p ON 1 = 1 -- < -- The ON condition makes it a CROSS JOIN
É aqui que a junção interna pode realmente ser vista como a junção cruzada com resultados que não correspondem à condição removida. Aqui, nenhuma das linhas resultantes é removida.
Usar INNER JOINpara obter o resultado de um LEFT OUTER JOINtambém requer truques. Está omitido.
JUNTA EXTERNA ESQUERDA
LEFT JOINresulta em linhas como A idéia geral / CROSS JOIN:
SELECT *
FROM citizen c
LEFT JOIN postalcode p ON 1 = 1 -- < -- The ON condition makes it a CROSS JOIN
LEFT JOINresulta em linhas como A idéia geral / 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
Os problemas com o diagrama de Venn
Uma pesquisa de imagens na Internet em "sql join cross inner outer" mostrará uma infinidade de diagramas de Venn. Eu costumava ter uma cópia impressa de uma na minha mesa. Mas há problemas com a representação.
O diagrama de Venn é excelente para a teoria dos conjuntos, onde um elemento pode estar em um ou nos dois conjuntos. Mas para bancos de dados, um elemento em um "conjunto" parece, para mim, uma linha em uma tabela e, portanto, também não está presente em nenhuma outra tabela. Não existe uma linha presente em várias tabelas. Uma linha é exclusiva para a tabela.
As junções automáticas são um caso de canto em que cada elemento é de fato o mesmo nos dois conjuntos. Mas ainda não está livre de nenhum dos problemas abaixo.
O conjunto Arepresenta o conjunto à esquerda (a citizentabela) e o conjunto Bé o conjunto à direita (a postalcodetabela) na discussão abaixo.
CROSS JOIN
Todos os elementos de ambos os conjuntos são combinados com todos os elementos do outro conjunto, o que significa que precisamos de Aquantidade de todos os Belementos e Bquantidade de todos os Aelementos para representar adequadamente esse produto cartesiano. A teoria dos conjuntos não é feita para vários elementos idênticos em um conjunto, então acho que os diagramas de Venn representam adequadamente impraticável / impossível. Parece que não UNIONse encaixa.
As linhas são distintas. São UNION7 linhas no total. Mas eles são incompatíveis para um SQLconjunto de resultados comum . E não é assim que CROSS JOINfunciona:
Tentando representá-lo assim:
..mas agora parece apenas um INTERSECTION, o que certamente não é . Além disso, não há nenhum elemento no INTERSECTIONque está realmente em qualquer um dos dois conjuntos distintos. No entanto, parece muito com os resultados pesquisáveis semelhantes a este:
Para referência, um resultado pesquisável para CROSS JOINs pode ser visto em Tutorialgateway . O INTERSECTION, assim como este, está vazio.
JUNÇÃO INTERNA
O valor de um elemento depende da JOINcondição. É possível representar isso sob a condição de que cada linha se torne exclusiva para essa condição. O significado id=xé verdadeiro apenas para uma linha. Quando uma linha na tabela A( citizen) corresponde a várias linhas na tabela B( postalcode) sob a JOINcondição, o resultado tem os mesmos problemas que CROSS JOIN: A linha precisa ser representada várias vezes e a teoria dos conjuntos não é realmente feita para isso. Sob a condição de exclusividade, o diagrama pode funcionar, mas lembre-se de que a JOINcondição determina a colocação de um elemento no diagrama. Observando apenas os valores da JOINcondição com o restante da linha logo após o passeio:
Essa representação se desfaz completamente ao usar a INNER JOINcom uma ON 1 = 1condição que a transforma em a CROSS JOIN.
Com um self- JOIN, as linhas são de fato elementos identais em ambas as tabelas, mas representam as tabelas como ambas Ae Bnão são muito adequadas. Por exemplo, uma auto- JOINcondição comum que faz com que um elemento Acorresponda a um elemento diferente em B é ON A.parent = B.childfazer a correspondência de Apara Belementos separados. Dos exemplos que seriam SQLassim:
SELECT *
FROM citizen c1
JOIN citizen c2 ON c1.id = c2.leader
Significado Smith é o líder de Green e Jensen.
JUNÇÃO EXTERNA
Novamente, os problemas começam quando uma linha possui várias correspondências com as linhas na outra tabela. Isso é ainda mais complicado, pois OUTER JOINpode corresponder ao conjunto vazio. Mas, na teoria dos conjuntos, a união de qualquer conjunto Ce de um conjunto vazio é sempre justa C. O conjunto vazio não adiciona nada. A representação disso LEFT OUTER JOINé geralmente apenas mostrando tudo Apara ilustrar que as linhas Asão selecionadas independentemente de haver uma correspondência ou não B. Os "elementos correspondentes", no entanto, têm os mesmos problemas que a ilustração acima. Eles dependem da condição. E o conjunto vazio parece ter vagado até A:
Cláusula WHERE - fazendo sentido
Localizando todas as linhas de a CROSS JOINcom Smith e código postal na Lua:
SELECT *
FROM citizen c
CROSS JOIN postalcode p
WHERE c.name = 'Smith'
AND p.area = 'Moon';
Agora, o diagrama de Venn não é usado para refletir o JOIN. É usado apenas para a WHEREcláusula:
..e isso faz sentido.
Quando INTERSECT e UNION fazem sentido
INTERSECT
Como explicado, um INNER JOINnão é realmente um INTERSECT. No entanto, INTERSECTs pode ser usado em resultados de consultas separadas. Aqui, um diagrama de Venn faz sentido, porque os elementos das consultas separadas são de fato linhas que pertencem a apenas um dos resultados ou a ambos. A interseção obviamente retornará apenas resultados onde a linha estiver presente nas duas consultas. Isso SQLresultará na mesma linha que a acima WHERE, e o diagrama de Venn também será o mesmo:
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';
UNIÃO
Um OUTER JOINnão é um UNION. No entanto, UNIONtrabalhe nas mesmas condições que INTERSECT, resultando em um retorno de todos os resultados combinando os dois 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';
que é equivalente a:
SELECT *
FROM citizen c
CROSS JOIN postalcode p
WHERE c.name = 'Smith'
OR p.area = 'Moon';
..e fornece o resultado:
Também aqui um diagrama de Venn faz sentido:
Quando não se aplica
Uma observação importante é que isso só funciona quando a estrutura dos resultados dos dois SELECTs é a mesma, permitindo uma comparação ou união. Os resultados desses dois não permitirão que:
SELECT *
FROM citizen
WHERE name = 'Smith'
SELECT *
FROM postalcode
WHERE area = 'Moon';
.. tentar combinar os resultados com UNIONdá uma
ORA-01790: expression must have same datatype as corresponding expression
Para mais informações, leia Diga NÃO aos diagramas de Venn ao explicar JOINs e sql joins como diagrama de venn . Ambos também cobrem EXCEPT.
