Комментарии 30
я склоняюсь к тому чтобы
Предлагаете изменить стандарт или просто не учить людей стандарту, что бы они на сложных вещах ошибались? Если стандарту всё же учить, диаграммы Венна не подходят.
Как диаграммы Венна покажут пересечение ключей при расчёте накопительного итога?
Что касается накопительный итог — не совсем понимаю что имеется в виду. Если можно поясните пожалуйста на примере?
Что касается накопительный итог — не совсем понимаю что имеется в виду. Если можно поясните пожалуйста на примере?
Это, например, когда у вас
FROM A JOIN B ON B.date <= A.date
Мне кажется что сразу становится понятным что берется просто декартово произведение таблиц и фильтруется по значению.
Случай с JOIN конечно не покроет того случая когда нужно взять левый или проавый JOIN: FROM A LEFT JOIN B ON B.date <= A.date Но это уже как бы гангстерский метод получения итогов. Я скорее применил что-то вроде этого запроса
SELECT ID, (SELECT SUM(amount) FROM B WHERE B.date <= A.date) as total_amouint FROM A
И да, автор статьи немного смешал понятия (то есть статья, в большей степени, академическая, чем промышленная). Обычно в качественно спроектированных БД, которые эксплуатируются в реальной жизни соединения (JOIN) происходят по ключам (первичные-внешние), в ключах не бывает NULL'ов и так далее. Но так бывает не всегда. О чём, собственно, и статья.
почему бы не сделать семантическое разделение
Вы не предлагаете его нарушить, вы видимо предлагаете его поменять.
Про накопительный итог вам ниже рассказали. Каким образом диаграммы Венна покажут пересечение ключей при расчёте накопительного итога?
можно задавать условия соединения двух таблиц в WHERE а условия фильтрации в JOIN
Нельзя. LEFT JOIN не взаимозаменяем с WHERE, если есть null.
Кажется мне, проблема веб-разработчиков, отвечающих на вопросы по SQL скорее в том, что у людей нет интуитивного понимания концепций SQL. Мы просто не встречаем их в быту. И без опыта близкого общения с базой, многие вещи принимаются интуитивно на основе похоже звучащих (выглядящих) бытовых концептов, и соответственно, не правильно. Плюс туториалы и объяснения «на пальцах».
В целом, про что ни спроси в плане SQL и реляционных баз, чаще всего в ответ получишь логично звучащее, но неверное мнение. И не было бы в этом ничего странного (технология старая и довольно сложная), если бы язык запросов не назывался Simple Query Language.
Боюсь, что в предыдущей статье мой комментарий потеряется, поэтому пишу здесь.
Вроде же sql — structured query language, язык структурированных запросов.
Мне кажется, что zetroot имел в виду, что аббревиатура SQL расшифровывается как Structured Query Language, а не как Simple Query Language. Что есть абсолютная правда, см. например https://en.wikipedia.org/wiki/SQL
Визуализацию нужно повернуть на 45 градусов, и поменять в ней таблицы местами.
Вроде бы получилась простая визуализация. Хотя в ней есть ограничения: здесь показан случай, когда в ON записано равенство, а не что-то хитрое (любое булево выражение).
Отличие "любого булева выражения" от равенства — лишь в том, что "любые булевы выражения" чаще дают дублирующиеся строки. Но поскольку вы специально подобрали совпадающие идентификаторы — никакого отличия в визуализации не будет.
Диаграммы просты и понятны, а JOIN, ИМХО, в 99% случаев идет по ключу. Не знаю, как у других, а у меня лично за 20 лет программирования ни разу не возникла необходимость использовать какие-то другие поля.
Это, примерно, как с математикой — в школе нас несколько лет учат, что квадратный корень из отрицательного числа взять нельзя, а в институте внезапно появляется мнимая единица.
Кстати, а как же FULL OUTER JOIN? Ну так, чисто для полноты картины.
Самый банальный вопрос, на котором многие тупят на собеседовании — что будет, если среди значений попадётся null?
И хорошо, если сумеет вспомнить, что по стандарту null не равен ничему. Но сумеет ли домыслить результат?
Часто может для left join получить вот такую табличку:
А должен был бы получить:
И даже если нарисует, поймёт ли, почему так? Что там ещё сокрыто под этими null-ми?
Куда нагляднее, если добавить ещё один столбец с данными и посмотреть на результат (кстати, многие осилив пример из статьи, сливаются на таком простом усложнении):
CREATE TABLE t1 (id int, v varchar(1));
CREATE TABLE t2 (id int, v varchar(1));
INSERT INTO t1
values
(1, 'a'),
(null, 'b'),
(1, 'c'),
(6, 'd'),
(5, 'e'),
(null, 'f');
INSERT INTO t2
VALUES
(1, 'a'),
(1, 'b'),
(2, 'c'),
(null, 'd'),
(3, 'e'),
(5, 'f'),
(null, 'g');
SELECT t1.id, t2.id
FROM t1
LEFT JOIN t2
ON t1.id = t2.id;
SELECT t1.v, t2.v
FROM t1
LEFT JOIN t2
ON t1.id = t2.id;
Первый select вернёт данные для второй картинки:
А что вернёт второй select?
Что в виде наглядной таблички выглядит так:
join — это скорее декартово произведение, чем пересечение.
Не просто «скорее»: соединение как раз и определяется как декартово произведение, к которому применена выборка по указанному условию соединения. В SQL это легко увидеть, например:
SELECT t1.id, t2.id
FROM t1
INNER JOIN t2
ON t1.id = t2.id
эквивалентно декартовому произведению с условием:
SELECT t1.id, t2.id
FROM t1, t2
WHERE t1.id = t2.id
или используем альтернативный синтаксис с CROSS JOIN:
SELECT t1.id, t2.id
FROM t1
CROSS JOIN t2
WHERE t1.id = t2.id
Так и хочеться набросить что web девелоперы не могут в алгебру, но собственно вот из учебных материалов:
http://www.mstu.edu.ru/study/materials/zelenkov/ch_4_4.html
СОЕДИНЕНИЕ
Данная операция имеет сходство с ДЕКАРТОВЫМ ПРОИЗВЕДЕНИЕМ. Однако, здесь добавлено условие, согласно которому вместо полного произведения всех строк в результирующее отношение включаются только строки, удовлетворяющие опредленному соотношению между атрибутами соединения (А1,A2) соответствующих отношений.
И да, что у вас там в постгре лежит и почему вы джойните диапазоны ipшников - это конечно отдельный вопрос
Понимание джойнов сломано. Продолжение. Попытка альтернативной визуализации