Скажем нет диаграммам Венна для SQL джойнов

Статья основана на недоступной в рф статье.

Начиная с 2016 года идёт волна, чтобы остановить использование Диаграмм Венна (используемых для объяснения множеств) для объяснения SQL джойнов. Забив в поисковик джойны, мы получим следующую картинку:

Что меня действительно раздражает, так это то, что вся эта смесь JOIN и теории множеств даже не имеет смысла. Как только ваше объяснение должно будет включать фразу «ГДЕ A равно NULL» в, казалось бы, произвольных местах, люди подумают, что вам нужно запоминать произвольные заклинания, чтобы заставить все работать — что по праву звучит ТЯЖЕЛО!

Корни SQL лежат в реляционной алгебре, а не в теории множеств. Фактически, то, как я объясняю вещи людям, дает аналогичный результат, но, по-видимому, происходит несколько в обратном направлении от формального способа.

Здесь и далее примеры автора по вымышленной вселенной с Годзиллой.

Будем использовать 2 таблицы:

Где в таблице А будет принадлежность города стране, а в таблице Б, сколько раз Годзилла атаковала город.

Теоретически конструкция JOIN выглядит следующим образом:

Select _fields_
FROM A
JOIN B ON on_conditions
WHERE where_conditions

Итого в блоке select мы перечисляем поля из одной или двух таблиц, задаем условие соединения в ON (результатом сравнения должно быть значение boolean – true/false) и указываем фильтр для итоговой выборки (аналогично результат да/нет).

Простейший запрос на объединение этих таблиц (INNER JOIN) будет выглядеть следующим образом:

SELECT A.City_name, Godzilla_attacks
from A
JOIN B on A.City_name = B.City_name

И таким образом мы будем сравнивать построчно все строки из таблиц А и В. Где условие будет выполнено, они попадут в результирующий набор. Когда перебор будет завершен, результирующий набор вернется к нам для дальнейшей обработки.

Следующий популярный джойн – LEFT JOIN (а в результате эти два джойна и составляют 99,9% процентов всех джойнов), будет выглядеть следующим образом:

SELECT A.City_name, Godzilla_attacks 
from A LEFT 
JOIN B on A.City_name = B.City_name

В результате запрос аналогичен предыдущему, кроме случая несовпадения строки из таблицы А и таблицы В – тогда в результирующий набор будут добавлены значения из таблицы А и пустые (NULL) значения по шаблону из таблицы В. Динамически это можно изобразить:

На этом коротком превью мы рассмотрели механизм работы самых популярных джойнов, но здесь важно сделать важное замечание – если условие у вас написано синтаксически верно (результат булево значение – true/false), но с человеческой логики неправильно – PostgreSQL и другие СУБД вам в этом не помогут и не напишут замечание или ошибку.

Посмотрим на примере сумасшедшего нелогичного запроса:

SELECT A.City_name, B.City_name, Godzilla_attacks 
from A 
LEFT JOIN B 
  on (A.Country = ‘USA’ and B.Godzilla_attacks = 2) 
  OR B.Godzilla_attacks = 13

Условие объединения – Годзилла атаковала американские города два раза или атаковала 13 раз – абсолютно нелогичный запрос, но ошибки не будет:

Логика условий лежит полностью на плечах разработчика!

Надеюсь вам стало чуть понятнее, как работают SQL джойны под капотом.