Как найти в таблице A записи, которых нет в B

что-то вроде where A.column1 is not IN B если бы был такой синтаксис

Типа вложенные запросы? SELECT * FROM A WHERE column1 NOT IN (SELECT column1 FROM B)

Но вообще это каким-то вариантом джойна решается по идее

Left join ... where b.id is null что-ли?

Да, вроде получилось. Чего-то я просто запутался немного.

Спасибо всем за подсказки!

Как вариант:

select A.* from A left join B on (A.column1 = B.column1) where B.id is null;

Почитал каменты. Стало грустно. Если трудно читать книжки, может хоть картинка поможет ))

https://external-preview.redd.it/M5QHWsp2vgZ-3QDZ4m-qS58lsOUgDNHau8trSFzS8H0....

SELECT * FROM A WHERE column1 NOT IN (SELECT column1 FROM B)

Так не надо делать, это плохо оптимизируется и неправильно работает с NULL:

https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_NOT_IN

Правильный ответ дал looper.

ТС сам напрашивался на это

Правильный ответ использовать NOT EXISTS

А левый джойн с нулл фильтром - неправильный ответ? В чем разница будет?

Какая субд? Разница по времени может быть существенная у разных запросов.

Не поможет. По смыслу картинок помог бы left join, но увы. И там вообще-то имена столбцов разные, даже тип не совсем одинаковый и вообще таблица B - это уже результат join, я просто не стал усложнять в исходном сообщении.

Вот от MrClon сработало. И оно может не совсем хорошо, как заметил slovazap но в моем случае все нормально было. Собственно, я даже как бы знал этот вариант, упомянув про NOT IN, но затупил сильно.

Еще раз спасибо за подсказки.

Вообще-то ms sql. // И покраснел ;-) Ну пришлось.

Впрочем для данного случая не важно было. Ничего специфичного не было, запросы не регулярные, база скромная по размерам, всего где-то 500K записей. И отработало быстро даже без оптимизаций.

А в чем увы-то, объясни(-те). Джойнить с результатом джойна не запрещено.

select a.*
from a
left join (
  select
    c.column as column,
    1 as present
  from c
  inner join d
    on c.d_id = d.id
) b
  on a.column = b.column
where b.present is null

Запрос вида

SELECT * FROM A WHERE column1 NOT IN (SELECT column1 FROM B)

NOT EXISTS

left join правильней всего, по-моему. Not exist оптимизатор приведёт к left join, если достаточно умный, а если недостаточно, то будет по каждому id одной таблицы лезть в другую вместо одновременного итерирования по двум таблицам.

Про join не знаю - надо планы смотреть, но скорее всего тоже должно работать. Поинт в том что NOT IN - точно нет.

left join у меня почему-то не сработал. Вернее результат join и left join был одинаковым (как и right join). Может это мелкомягкие приколы такие, может я чего не понял.

Может порядок джойнов сыграл? Ты часом не «from a left join b on expr inner join c on expr» делал без субселекта или скобок?

Почитал каменты. Стало грустно. Если трудно читать книжки, может хоть картинка поможет ))
https://external-preview.redd.it/M5QHWsp2vgZ-3QDZ4m-qS58lsOUgDNHau8trSFzS8H0....

Картинка - чушь собачья. Операция джоина - это не пересечение множеств, это перемножение матриц, а это принципиально иная операция, дающая произведение размерностей вместо сохранения размерности на картинке.

А левый джойн с нулл фильтром - неправильный ответ? В чем разница будет?

Оптимизаторы на хороших движках такой нулл-фильтр просто закидывает в условия джоина, и разница оказывается никакая.

left join правильней всего, по-моему. Not exist оптимизатор приведёт к left join, если достаточно умный, а если недостаточно, то будет по каждому id одной таблицы лезть в другую вместо одновременного итерирования по двум таблицам.

SELECT * FROM A WHERE column1 NOT IN (SELECT column1 FROM B).
и.
SELECT A.* FROM A LEFT JOIN B ON (A.column1 = B.column1) WHERE B.id is null.
внезапно, выдают разные результаты.
Если в таблице B есть индекс по id, то обычно оба запроса будут использовать именно его, таким образом выдавая разные результаты с равной скоростью.

Я про not exist говорил, а не про not in.

Я про not exist говорил, а не про not in

Вот они как раз примерно одинаковые по функциям, хоть not in в некоторых СУБД плохо обрабатывается. Ну то есть, например, в PostgreSQL и Firebird если у тебя хоть одно значение из вложенного запроса NULL, то not in возвращает «ложь» независимо от остальных значений.

вот первая ссылка в гугле

SELECT * FROM A WHERE column1 NOT IN (SELECT column1 FROM B).
и.
SELECT A.* FROM A LEFT JOIN B ON (A.column1 = B.column1) WHERE B.id is null.

так ты это, делаешь чушь надо так

SELECT A.* FROM A LEFT JOIN B ON (A.column1 = B.column1) WHERE B.column1 is null.

Картинка - чушь собачья. Операция джоина - это не пересечение множеств, это перемножение матриц

Ты больной, ты сам чушь собачью сказал, нет там перемножения матриц, там даже матриц нет!

https://ru.wikipedia.org/wiki/Матрица_(математика)#Умножение_матриц

Матрицы в алгоритмах тупого перебора?

Забавно.

https://ru.wikipedia.org/wiki/Матрица_(математика)#Умножение_матриц

У тебя шизофрения? Сам себя опровергаешь? Или просто сам не прочёл?

Матрицы в алгоритмах тупого перебора?

А что не так? Произведение является комбинацией каждого элемента одного отношения с другим. Можно называть это векторами, но векторы - это подвид матрицы. Произведение коротежей - это тупо их объединение. По крайней мере что угодно из этого лучше упомянутой выше картинки, которая только запутывает, а не поясняет.

А что не так?

Да всё не так!

Произведение является комбинацией каждого элемента одного отношения с другим.

Умножение матриц A B, реже со знаком умножения A × B — есть операция вычисления матрицы C, каждый элемент которой равен сумме произведений элементов в соответствующей строке первого множителя и столбце второго.

Количество столбцов в матрице A должно совпадать с количеством строк в матрице B, иными словами, матрица A обязана быть согласованной с матрицей B. Если матрица A имеет размерность m × n, B — n × k, то размерность их произведения A B = C есть m × k.

Можно называть это векторами, но векторы - это подвид матрицы.

Кончай чушь пороть, ей больно. Тебе можно нормальным назвать, но у тебя явное слабоумие!

Произведение коротежей - это тупо их объединение.

Неверно. Соединение ­— это декартово произведение множеств кортежей и выборка по предикату отношения!

У нас реляционная алгебра, а не матричная, и у нас это множества, а не матрицы!

Ты матричное произведение с декартовым попутал.

Говоря человеческим языком, надо найти в таблице A записи, которых нет в B (сами структуры таблиц немного отличаются).

Тебе уже сказали про NOT IN, годится для единичных/ручных запросов, но этот тип запросов убийца перформанса, никак тут индексы не участвуют.

Ты матричное произведение с декартовым попутал.

Нет он попутал посимвольное сравнение с умножением.

Он прав. Я попутал матричное умножение с декартовым. Самое близкое - это декартовое умножение.

Где в посимвольном сравнении есть умножение?

Нигде. Его нет в джоине. Ты выбираешь из произведения нужные тебе элементы.

Вот например - вопрос на засыпку (да лично тебе). Как бы ты наиболее оптимально сравнивал строки на не схожесть?

Зависит от задачи.

задача описана в топике.

Я думал строки - это наборы символов. Ты про исходную задачу ОП-а?
SELECT * FROM A WHERE NOT EXISTS (SELECT B.column1 FROM B WHERE A.column1 = B.column1)
Естественно, должен быть индекс по column1 в B.

Я про то как бы ты реализовал на уровне машинных команд.

Ну или хотябы на уровне булевой алгебры.

Оптимизатор сам за меня говорит:
PLAN (T_911973 INDEX (XT_911973_SERVER_ID))
PLAN (R NATURAL)
Последовательный проход по таблице A с проверкой условия вспомогательным запросом по индексу в таблице B.

Судя по всему ты ни в матричных операциях не разбираешься ни в булевой алгебре...

ок

Картинка - чушь собачья. Операция джоина - это не пересечение множеств, это перемножение матриц, а это принципиально иная операция, дающая произведение размерностей вместо сохранения размерности на картинке.

картинка показывает суть операций с множествами, коими является реляционная модель данных. какое отношение имеет реляционная алгебра к теории множеств - найдете самостоятельно.

надеюсь инженерное любопытство возьмёт верх над юношеским максимализмом.

Джойнить не только по (column = column) можно, так что формально картина шире, чем на картинке.