Суть - создать условие которое будет отрабатывать как в случае задания параметра отбора так и в случае его отсутствия.

Даю два варианта на выбор. Который быстрее и почему?

1. выбор когда &Номенклатура = значение(Справочник.Номенклатура.ПустаяСсылка) тогда Истина иначе Номенклатура = &Номенклатура конец

2. &Номенклатура = значение(Справочник.Номенклатура.ПустаяСсылка) или Номенклатура = &Номенклатура

(0) для птяницы рановато - подними ветку в пятницу - может народ и поймет твой стеб

(0) Второе, разумеется.

(0) Используй построитель

ГДЕ
  &УсловиеНоменклатура

в коде:

  ТекстЗапроса = СтрЗаменить(ТекстЗапроса,"&УсловиеНоменклатура",?(ЗначениеЗаполнено(Номенклатура),"Номенклатура = &Номенклатура","ИСТИНА"));

(4)
Тогда уж лучше использовать Построитель

(5) я не против, но не люблю его программно дергать, только для отчетов

можно в иерархии юзать

(4) За такое нужно руки отрубать

(3) ответ не верный - или в условии может привести к тому, что СУБД не сможет использовать индексы таблиц и будет выполнять сканирование, что увеличит время запроса и вероятность возникновения блокировок.
(4) это принесение универсализации в жертву скорости. Кроме того это приведет к невозможности использования конструктора запроса (наличие шаблонов в тексте запроса).

(7) в отношении справочника да, но в отношении документа?

(9) как раз конструктором это прекрасно открывается
и по поводу скорости ты как раз не прав

Еще можно так:

ВЫБРАТЬ
    СправочникНоменклатура.Ссылка КАК Номенклатура
ИЗ
    Справочник.Номенклатура КАК СправочникНоменклатура
ГДЕ
    &Номенклатура = ЗНАЧЕНИЕ(справочник.Номенклатура.ПустаяСсылка)

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
    СправочникНоменклатура.Ссылка
ИЗ
    Справочник.Номенклатура КАК СправочникНоменклатура
ГДЕ
    СправочникНоменклатура.Ссылка = &Номенклатура

(10) Отбирай значение справочника в врт потом соединяй с документом

(9) Где в посторителе будет или??

(8) И такие дятлы, как (4) еще нас пытаются чему -то учить.

(9) "или в условии может привести к тому, что СУБД не сможет использовать индексы таблиц и будет выполнять сканирование, "

Пальцем в попу.

(11) вы правы открывается у вас не шаблон а условие целиком. но то, что вы предлагаете это модификация текста в зависимости от условий. здесь же речь же об универсальном тексте.

Номенклатура В (значение(Справочник.Номенклатура.ПустаяСсылка), &Номенклатура)

(12) и возможно это будет самый быстрый вариант.

(17) а я не спорю, скажем это изобретение велосипеда построителя

в справочнике номенклатуры не может быть пустых ссылок )))

(18) не верно условие в 0 другое

(19) самый быстрый вариант это построитель

(22) именно оно

(18) в общем случае не подходит, т.к. поле Номенклатура может быть не заполнено

(16) "Настольная книга 1С эксперта" стр.193 почитайте

(24) Да только в 0 если пустая ссылка то выбираем все, если заполнено то выбираем что равно, а в (18)  мы документы с не заполненной номенклатурой выберем по любому.

(26) "может привести", Gorr, "может привести".

Филлипов поленился физику индексов описывать, так как не рассчитывал, что 1Снеги осилят это, поэтому дал "безопасную" рекомендацию.

(27) Да, не смог узреть & под таким углом.

В шаблонах РЛС обычно пишут так (пример):


ГДЕ
(ТаблицаДокумента.ДокументОснование В (&СписокДокументовОснований)
ИЛИ НЕ 1 В
(ВЫБРАТЬ ПЕРВЫЕ 1
1
ИЗ
ТаблицаДокумента КАК ТаблицаДокумента
ГДЕ
ТаблицаДокумента.ДокументОснование В (&СписокДокументовОснований)))


на быстроту, конечно, не претендует, но зато универсально.

(26) Так и знал, что настольная книга попала в шаловливые ручки. Читайте полностью, вдумчиво. Сверяйте с планами на практике. А потом делайте выводы.

(28) Ну так (0) не просто так и появилась. Просвятите пожалуйста нас о физике индексов и чем рекомендация по запроса данная в 13м правиле неверна.

(15)
Цитирую "И такие дятлы, как " ... " еще нас пытаются чему -то учить"
(18) (30)

Кстати, думаю, что в конечном счете (31) на уровне СУБД превращается в (12), так как оптимизатор запросов SQL - не дурак и оператор "В" он скорее всего преобразует в джойн, а "ИЛИ" в объединение

(35) Зря так думаете

(36) ну я не тестировал, но почему нет? на досуге гляну план такого запроса

(37)Задача оптимизатора понять какая есть статистика и как с ней работать "или" сильно вводит его в заблуждение он не знает что должно вернутся, а времени подумать у него нет.

(38) Плюс иногда на моей практике встречались умышленно не оптимальные запросы. На пример требовалось чтоб некоторые строки в результат попали n раз.

(39) такое, конечно, лучше делать через объединение. ну, значит вариант в (12) в целом более универсален

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

(38) "ИЛИ" никак не вводит SQL в заблуждение.
ИЛИ отлично применяется к одному поля таблицы, хоть испляшись.

ИЛИ опасно для нескольких полей.

(0) Лучше первый вариант, "ИЛИ" в условие запроса лично я стараюсь не использовать, в некоторых случаях запрос работает гораздо медленнее.

(42)ага только вот оптимизатор не знает сколько полей оберется в таблицу которая получается после "или" 1 или все  и что делается дальше с этой таблицей

(44) Оптимизатор об этом прекрасно знает. И не полей, а записей.

" и что делается дальше с этой таблицей"

А какая разница, что с ней делается потом. Я думаю, вы это окончание написали просто, чтобы было, для придания веса фразе, не так ли?

(0) неужели проще спросить на форуме, чем узнать у замера производительности/профайлера/секундомера/илиЧтоТамУВасЕсть?

(45) а про физику индексов вы, наверное, так же подумав добавили для предания веса фразе?

(45) насчет поправки согласен  Записей. Вопрос что "где" накладывается уже после соединений по факту на результирующую таблицу и сколько там будет записей оптимизатор зачастую не знает да ему и все равно.Хотя да в целом вы скорее всего правы на быстродействии это врят ли скажется. Вот если "или" стоит в условиях соединения или в параметрах вирттаблици тогда да скорее всего будет не оптимально.