Общая идея
Пожалуйста , смотрите ответ на Мартина Смита за лучшие illustations и объяснения различных соединений, в том числе и в особенности различия между FULL OUTER JOIN, RIGHT OUTER JOINи LEFT OUTER JOIN.
Эти две таблицы образуют основу для представления JOINниже:
CROSS JOIN
SELECT *
FROM citizen
CROSS JOIN postalcode
Результатом будут декартовы произведения всех комбинаций. Никаких JOINусловий не требуется:
ВНУТРЕННЕЕ СОЕДИНЕНИЕ
INNER JOIN так же, как просто: JOIN
SELECT *
FROM citizen c
JOIN postalcode p ON c.postal = p.postal
Результатом будут комбинации, удовлетворяющие требуемому JOINусловию:
ЛЕВЫЕ НАРУЖНЫЕ
LEFT OUTER JOIN такой же как LEFT JOIN
SELECT *
FROM citizen c
LEFT JOIN postalcode p ON c.postal = p.postal
Результатом будет все, citizenдаже если нет совпадений postalcode. Снова требуется JOINусловие:
Данные для игры
Все примеры были запущены на Oracle 18c. Они доступны на dbfiddle.uk, откуда также пришли скриншоты таблиц.
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;
Размытые границы при игре с JOINиWHERE
CROSS JOIN
CROSS JOINв результате чего строки в качестве общей идеи / INNER JOIN:
SELECT *
FROM citizen c
CROSS JOIN postalcode p
WHERE c.postal = p.postal -- < -- The WHERE condition is limiting the resulting rows
Использование CROSS JOINдля получения результата LEFT OUTER JOINтребует трюков, таких как добавление в NULLстроку. Это опущено.
ВНУТРЕННЕЕ СОЕДИНЕНИЕ
INNER JOINстановится декартовой продукцией. Это так же, как общая идея / CROSS JOIN:
SELECT *
FROM citizen c
JOIN postalcode p ON 1 = 1 -- < -- The ON condition makes it a CROSS JOIN
Именно здесь внутреннее соединение действительно можно рассматривать как перекрестное соединение с результатами, не соответствующими удаленному условию. Здесь ни одна из полученных строк не удаляется.
Использование INNER JOINдля получения результата LEFT OUTER JOINтакже требует хитростей. Это опущено.
ЛЕВЫЕ НАРУЖНЫЕ
LEFT JOINприводит к строкам как общая идея / CROSS JOIN:
SELECT *
FROM citizen c
LEFT JOIN postalcode p ON 1 = 1 -- < -- The ON condition makes it a CROSS JOIN
LEFT JOINприводит к строкам как общая идея / 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
Проблемы с диаграммой Венна
Поиск в интернете по изображению "sql join cross inner external" покажет множество диаграмм Венна. Раньше у меня была печатная копия одного на моем столе. Но есть проблемы с представительством.
Диаграмма Венна отлично подходит для теории множеств, где элемент может быть в одном или обоих наборах. Но для баз данных мне кажется, что элемент в одном «наборе» является строкой в таблице и, следовательно, не присутствует ни в каких других таблицах. Нет такой вещи, как одна строка присутствует в нескольких таблицах. Строка уникальна для таблицы.
Самостоятельные объединения - это угловой случай, когда каждый элемент фактически одинаков в обоих наборах. Но это все еще не свободно ни от одной из проблем ниже.
Набор Aпредставляет собой набор слева ( citizenтаблица), а набор B- это набор справа ( postalcodeтаблица) в обсуждении ниже.
CROSS JOIN
Каждый элемент в обоих наборах сопоставляется с каждым элементом в другом наборе, что означает, что нам нужно Aколичество каждого Bэлемента и Bколичество каждого Aэлемента, чтобы правильно представить этот декартово произведение. Теория множеств не создана для нескольких идентичных элементов в наборе, поэтому я считаю, что диаграммы Венна правильно представляют ее непрактично / невозможно. Кажется, что это совсем не UNIONподходит.
Строки различны. Всего UNION7 строк. Но они несовместимы для общего SQLнабора результатов. И это совсем не так CROSS JOIN:
Попытка представить это так:
..но теперь это просто выглядит как INTERSECTION, что это, конечно, нет . Кроме того, в этом элементе нет ни INTERSECTIONодного из двух различных наборов. Тем не менее, это очень похоже на результаты поиска, похожие на это:
Для справки один результат поиска для CROSS JOINs можно увидеть на Tutorialgateway . Как INTERSECTIONи этот, пуст.
ВНУТРЕННЕЕ СОЕДИНЕНИЕ
Значение элемента зависит от JOINусловия. Это можно представить при условии, что каждая строка становится уникальной для этого условия. Значение id=xверно только для одного ряда. Как только строка в table A( citizen) соответствует нескольким строкам в table B( postalcode) при JOINусловии, результат имеет те же проблемы, что и CROSS JOIN: Строка должна быть представлена несколько раз, и теория множеств на самом деле не создана для этого. Хотя при условии уникальности диаграмма может работать, но имейте в виду, что это JOINусловие определяет размещение элемента на диаграмме. Глядя только на значения JOINусловия с остальной частью ряда только для поездки:
Это представление полностью расходится при использовании INNER JOINс ON 1 = 1условием, превращающим его в CROSS JOIN.
С self- JOIN, строки на самом деле являются идентичными элементами в обеих таблицах, но представляют таблицы как обе Aи Bне очень подходят. Например , общее само JOINусловие , которое делает элемент Aбудет сопрягать иной элемент в В ON A.parent = B.child, что делает матч с Aчтобы Bна отдельно элементах. Из примеров, которые будут SQLпохожи на это:
SELECT *
FROM citizen c1
JOIN citizen c2 ON c1.id = c2.leader
То есть Смит - лидер и Грина, и Дженсена.
НАРУЖНОЕ СОЕДИНЕНИЕ
Опять проблемы начинаются, когда одна строка имеет несколько совпадений со строками в другой таблице. Это дополнительно усложняется тем, что OUTER JOINможет соответствовать пустому набору. Но в теории множеств объединение любого множества Cи пустого множества всегда справедливо C. Пустой набор ничего не добавляет. Представление этого LEFT OUTER JOINобычно просто показывает все, Aчтобы проиллюстрировать, что строки Aвыбираются независимо от того, есть совпадение или нет B. Однако у «совпадающих элементов» есть те же проблемы, что и на иллюстрации выше. Они зависят от состояния. И пустой набор, кажется, забрел к A:
ГДЕ оговорка - смысл
Нахождение всех строк CROSS JOINсо Смитом и почтовым индексом на Луне:
SELECT *
FROM citizen c
CROSS JOIN postalcode p
WHERE c.name = 'Smith'
AND p.area = 'Moon';
Теперь диаграмма Венна не используется для отражения JOIN. Используется только для WHEREпредложения:
... и это имеет смысл.
Когда INTERSECT и UNION имеет смысл
ПЕРЕСЕЧЕНИЕ
Как объяснил, это INNER JOINне совсем INTERSECT. Однако INTERSECTs можно использовать по результатам отдельных запросов. Здесь диаграмма Венна имеет смысл, поскольку элементы отдельных запросов на самом деле являются строками, которые либо принадлежат только одному из результатов, либо обоим. Очевидно, что Intersect будет возвращать результаты только в том случае, если строка присутствует в обоих запросах. Это SQLприведет к тому же ряду, что и приведенный выше WHERE, и диаграмма Венна также будет такой же:
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
Ан OUTER JOINне а UNION. Однако UNIONработают в тех же условиях INTERSECT, что и возвращают все результаты, объединяющие оба параметра SELECT:
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';
что эквивалентно:
SELECT *
FROM citizen c
CROSS JOIN postalcode p
WHERE c.name = 'Smith'
OR p.area = 'Moon';
..и дает результат:
Также здесь имеет смысл диаграмма Венна:
Когда это не относится
Важным примечанием является то, что они работают только тогда, когда структура результатов двух SELECT одинакова, что позволяет сравнивать или объединять. Результаты этих двух не позволят это:
SELECT *
FROM citizen
WHERE name = 'Smith'
SELECT *
FROM postalcode
WHERE area = 'Moon';
.. пытается объединить результаты с UNIONдает
ORA-01790: expression must have same datatype as corresponding expression
Для дальнейшего интереса прочитайте Скажите НЕТ диаграммам Венна при объяснении СОЕДИНЕНИЙ, и соединения sql как диаграмму Венна . Оба также покрывают EXCEPT.
