Добрый день.
Есть справочник Контрагентов и регистр сведений с измерением Контрагент.
Нужно выбрать Контрагентов из справочника, которые отсутствуют в регистре. Первое, что приходит на ум это в условии - ГДЕ Контрагент НЕ В (Списке). Можно ли это же сделать соединением? Что будет работать быстрее? И самое главное, не соображу какое должно быть условие соединения ПО?

ГДЕ ЕСТЬNULL

соединение
+ где поле ЕСТЬ NULL

(1) +
ПО
   Контрагент.Ссылка = РегистрСведений.Контрагент

Условие ПО должно быть обычным, а вот потом в ГДЕ ЕСТЬ NULL

левое соединение по контрагенту и где контрагент есть нул

Сколько же таких вопросов будет, одинаковых?

(0) Операция IN, по словам знатоков SQL - это то же самое замаскированное соединение. Много раз запускал планы запроса - по показателю COST одно и то же.

Доподлинно на этот вопрос ответит план запроса - СУБД для одного и того же запроса может построить множество совершенно разные планов выполнения - одно и то же соединение может быть реализовано и как цикл в цикле (NESTED LOOPS), и как один проход по 2-м отсортированным таблицам (MERGE JOIN) в зависимости от того, какие индексы используются и какие объемы данных (если данных в таблице менее 20 - индексы использовать нерационально).

(7) сумневаюсь я однако. Ежели IN из select, то возможно, а если из простого перечисления IN ("а", "в" ...

(8) Из простого перечисления то же самое. Там это перечисление ("а","в") загоняется скулем в слежуебную табличку и дальше как обычно.

(9) Если быть точнее, то при небольшом количестве элементов условие IN ("а","в"...) разворачивается в плане запроса в несколько (Поле = "а" или Поле = "в" ...), а при большем количестве элементов уже через служебную табличку и соединения.

Вот насчет конкретных цифр при каком количестве элементов в списке какой вариант выполнения выбирает скуль не скажу, не знаю.

(11) Можно ли вообще узнать алгоритм выбора плана запроса или это коммерческая тайна Майкрософт?

v8: Как получить записи из первой таблицы которых нет во второй?

Только тестить на конкретном запросе и конкретной БД.

(12) Не знаю, но есть такое чувтство что толку от этого алгоритма особого не будет, так как при выборе плана запроса учитывается много всякой внутренней хрени о состоянии БД.

Спасибо всем за советы. В моем случае быстрей выполняется запрос с соединениями, хотя разница совсем небольшая и немного меняется при разных параметрах.
Запрос с ГДЕ, если его выполнять сразу же второй раз, выполняется намного быстрей. В то же время, скорость повторного выполнения запроса с соединениями не меняеться.

(16) То что написано в (7) и в моих постах это относится к  просто Где В () и внутреннему соединению.
Вот с Где НЕ В () все может быть по другому, точно не помню как оно разворачивается.

(16) Наверное, запрос с ГДЕ кэширует все это безобразие. Его имеет смысл, по-ходу, выполнять в том случае, если запрос выполняется с периодичностью, превышающей время жизни этого кэша.

+(18) Пардон, имеет смысл, если периодичность запроса меньше периода жизни кэша.

я знаю как решить эту задачу тремя способами:
1. через конструкцию В к подзапросу
2. через левое соединение и проверку NULL
3. через объединение в подзапросе и суммирование (извращенный метод!)

(20) Третий способ для 7.7 без 1С++ - ни конструкцию В (внутри другого запроса) нельзя сделать, ни ЛЕВОЕ СОЕДИНЕНИЕ.

(20) Вы про Oracle и другие бд забываете. Oracle не любит временные таблицы, вернее любит, но места на освобождает, в отличие от ms