iBase.ru Forum

Подскажите, как выбрать записи из таблицы, которых нет во 2-ой таблице.

Т.е.:
Table1 с полями ID, Name
Table2 с полями ID2, ID

Нужно выбрать все записи таблицы Table1.ID, которых нет в Table2.ID

Как вариант:
select * from table1 t1
left join table t2 on t1.id=t2.id
where t2.id is null
или через exists, но я его не люблю. Хотя то или иное решение имеют место быть в зависимости от объёма таблиц (текущего и расчётного)

xvv писал(а):или через exists, но я его не люблю. Хотя то или иное решение имеют место быть в зависимости от объёма таблиц (текущего и расчётного)

Интересно, а как ч-з exists? Запсией ~ 500 расчетные не более 3000

xvv писал(а):через exists, но я его не люблю.

И зря. EXISTS в таких запросах работает лучше на любом объёме данных и при любых условиях.
Ситуация может измениться только при одном условии - если LEFT JOIN перестанет работать рекурсивным перебором.

И больее логично, на мой взгляд. Спасибо.

Как ни странно, но в fb2.1 exist работает неплохо.
Так что возможно мой вариант будет медленне при прочих выборках.

xvv писал(а):Как ни странно, но в fb2.1 exist работает неплохо.

Как и на 2.0, и на 1.5, и на 1.0.
Хотелось бы поглядеть на пример, где exist будет медленнее чем left join, на любом из указанных серверов.
Хотя установленного 1.5 у меня нет, но для такого случая поставлю

ЗЫ: Left join я лично применяю для таких целей только в 1С. Эти лентяи до сих пор кореллирующие подзапросы не могут сделать...

Провел некоторое исследование по данному вопросу и предлагаю ознакомиться с результатами вот сдесь http://www.az-design.ru/Support/DataBas ... 0003.shtml

а чего сразу ID - bigint ? смущать неокрепшие умы?

да и вообще. "напугало неиспользование индексов".
A.ID NOT IN - здесь индекс никак
SELECT B.ID FROM B - здесь тоже индекс ни к селу ни к городу
попытка
SELECT B.ID FROM B ORDER BY B.ID - это вообще чума. order by по индексу идет по индексу и дергает записи чаще всего в "случайном" порядке с диска. Поэтому order by по индексу годится только для небольших выборок. А уж тем более здесь...

distinct - начиная с IB 6.0 также идет натуралом.

в общем, если оставить как есть, то я бы сопроводил комментариями.

Просто на рабочей базе уже один раз INT закончился теперь на всякий случай пишу так.

уже один раз INT закончился

ну-ка, ну-ка, поподробнее... часом, не один идентификатор для всех таблиц?

Код Счет-квитанции в едином рассчётно-кассовом центре. На самом деле проблема была в неправильном распределении диапазонов ID на филиалах при репликации средствами MSSQL.

так вот. почему я и спросил. Давайте, пока речь не идет о филиалах, указывать INT, а не BIGINT. А кому надо, потом сам разберется.

ага, я также проверил. Только меньше извращался. причём я ожидал что на примерно равных таблицах join догонит exist, но это оказалось не так.