Как правильнее? Регистр сведений.
Вариант 1.
CRM_ВзаимодействияСКлиентом.Регистратор ССЫЛКА Документ.CRM_ПредпринятоеДействие
Вариант 2.
НЕ ВЫРАЗИТЬ(CRM_ВзаимодействияСКлиентом.Регистратор КАК Документ.CRM_ПредпринятоеДействие) ЕСТЬ NULL

так читабельнее

(1) Да фиг с ней читабельностью. Как быстрее?

(2) сделай замер

Судя по пойманным запросам - таки первый.
Мне так кажется.
Но это не точно.

2 вариант не встречал ещё.

А что прям кардинально время выполнения меняется?:)
Я всегда 1 вариантом пользовался. По логике в 1 варианте 1 действие - проверка на тип, а во втором 2, попытка преобразования в нужный тип, и проверка на null

(0) вот тебе ответ
http://mikescherbakov.ru/vliyanie-konstruktsii-vyirazit-na-sql-zapros-i-ego-plan-na-polya-ne-sostavnyih-tipov/

(1) (4) (5)
Я тоже не встречал, но у меня вариант 2 работает быстрее первого, вот я и интересуюсь.

(7) Так это не в условии во-первых, во-вторых не для составного типа

(8) Попробуй еще вариант 3: "НЕ" размести не в начале, а перед ЕСТЬ

А потом вариант 4: "НЕ" размести после "ЕСТЬ"

ТипЗначения(Регистратор) = Тип(Документ.CRM_ПредпринятоеДействие)

пробовал?

(11) Медленнее получается
(12) Еще медленнее (11)

сами запросы скл сравнивал?

(14) Неа. Пока нет доступа. Как комп нормальный поставят, локально сервер разверну тогда посмотрю конечно.

а какая разница в замерах? может это просто пограшность?

Если сравнить время на отладку и время исполнения запроса,  умноженное на количество исполнений, что больше?

(0) ССЫЛКА проще, но она - только для ссылочных типов данных(как это не странно). Если в регистраторе будет Неопределено, то запрос в этом месте упадет.

И кстати второй вариант тоже с ошибкой падает для неопределено

(18) падает все же не по значению,а по типу поля.

3.Вариант 3. Явное соединение.

(16) Возможно.
(18) В регистраторе не может быть "неопределено"

(0) CRM_ВзаимодействияСКлиентом.Регистратор ССЫЛКА Документ.CRM_ПредпринятоеДействие

Пользуйтесь!
Это быстрее

вот факультативная ссцылочка, по п.2
https://www.mssqltips.com/sqlservertutorial/3203/avoid-using-not-equal-in-where-clause/

(13) А (10)?

(23) Спс

(23) Так не понял. ТО есть исходя из этого предложение "В" обрабатывается быстрее чем "<>" или "ИЛИ"

(26) Еще быстрее вместо "В" делать объединение с =, не?

Да, но слишком тяжелые для восприятия запросы получаются

+ (28)  И если нужно что то изменить, приходится во всех объединениях это изменять

(28) Вам шашечки или ехать?

Хотя насчет замены "В" на объединение с = лениво смотреть, но по идее платформа прекрасно сама это должна делать?

Хотя не, походу не делает...

(0) Бредовый вопрос :)

Сравнение поля тип конечно же быстрее

CRM_ВзаимодействияСКлиентом.Регистратор ССЫЛКА Документ.CRM_ПредпринятоеДействие

Вариант ниже это как чесать язык через з@дницу

НЕ ВЫРАЗИТЬ(CRM_ВзаимодействияСКлиентом.Регистратор КАК Документ.CRM_ПредпринятоеДействие) ЕСТЬ NULL

(33) Ну видимо у меня погрешность все же. Т.к.  "НЕ ВЫРАЗИТЬ(CRM_ВзаимодействияСКлиентом.Регистратор КАК Документ.CRM_ПредпринятоеДействие) ЕСТЬ NULL" - было быстрее.
Ну и не только я один юзаю сервер.

Поле ССЫЛКА .Тип
и
Тип(Поле) = Тип
в скл разварачиваются одинаково

выразить скорре всего вообще левое соединение будет. так что быстрее может быть только случайно

(36) Возможно ВЫРАЗИТЬ в условии будет влиять на получение полей запроса. Хотя там при получении полей у меня все тоже через ВЫРАЗИТЬ.

(37) проще самому соединение написать, чем 500 раз выразить

(36) Не будет там левое... Если бы точку поставил тогда да...
Выразить это типа приведение типа :) так кроме этого сравнение на null и ещё инверсия результата. Действий больше, чем просто проверка поля тип на цЫфирь, которую в запрос подставит 1с...

(34) что бы мерить нужно код определенно строить. Выносить запрос в общий, что бы он один раз парился и вызывать в цикле уже отпарсенный, что бы тест был корректным...

(40) вместо парился читать парсился

(0)
первый вариант - будет сравнение по полу Тип данных, на больших выборках свалится в сканирование таблицы.
второй вариант - 100% будет полное сканирование таблицы, так как будет CASE when ....

Еще вопрос тогда.
Я вижу что вот такие условия в запросе у меня оптимизатор неверно обрабатывает. (8.2.19)
ВЫБРАТЬ
    Номенклатура.Ссылка
ИЗ
    Справочник.Номенклатура КАК Номенклатура
ГДЕ
    ВЫБОР
            КОГДА &Фильтр = "ТипНоменклатуры"
                ТОГДА Номенклатура.ТипНоменклатуры = &ТипНоменклатуры
            КОГДА &Фильтр = "спТипНоменклатуры"
                ТОГДА Номенклатура.ТипНоменклатуры В (&спТипНоменклатуры)
            КОГДА &Фильтр = "ВидНоменклатуры"
                ТОГДА Номенклатура.ВидНоменклатуры = &ВидНоменклатуры
            КОГДА &Фильтр = "cgВидНоменклатуры"
                ТОГДА Номенклатура.ВидНоменклатуры В (&спВидНоменклатуры)
            ИНАЧЕ ИСТИНА
        КОНЕЦ
Переписал все на конструировании запроса. Сейчас быстрее но сложнее дорабатывать. т.к. запрос собирается из нескольких частей и условий.
Это норма или что то уже изменили в новых платформах?

(43) Вместо кейсов объединение лупить - это норма

А вот латиница в "cgВидНоменклатуры" - это не норма )

(45) Это просто для примера делал, там "спВидНоменклатуры"

(43) Чтобы не собирать запрос из несколько частей можно вставить все эти условия в запрос закомментированными, а потом один раз СтрЗаменить(ТекстЗапроса, "//ОтборНоменклатура", "")

(47) Вариант. Но конструктор запросов выкинет комментарии.

(48)Чтобы конструктор не выкидывал, можно ставить не "ОтборНоменклатура", а "&ОтборНоменклатура".
А потом СтрЗаменить(ТекстЗапроса, "&ОтборНоменклатура", "").

(48)Чтобы конструктор не выкидывал, можно ставить не "//ОтборНоменклатура", а "&ОтборНоменклатура".
А потом СтрЗаменить(ТекстЗапроса, "&ОтборНоменклатура", "").

(43) Может проще параметр заполнять, а не текст менять?

(51) А что это даст? Оптимизатор неверно прожует это условие.

Я предлагая всегда писать "В", а параметр либо список либо элемент

(48) Да, выкинет. Да, дорабатывать всё же сложнее чем в (43). Но! Так у тебя текст запроса не разбит на несколько кусков с кучей Если посередине (в общем случае). Наглядность такого запроса выше, его уже глазами можно читать.
Плюс при таком подходе конструктор запросов хоть открывается и можно посмотреть всё остальное. К тому же при точечных доработках всегда приходится добавлять кусочки запроса и комментарии. Т.е. в любом случае сделал текст конструктором, скопировал что надо, откатил текст, вставил только свой кусочек, не меняя форматирования всего запроса. При таком подходе все эти комментарии нормально живут.