При установке ограничения на выборку в запросе с помощью фильтра по значению поля составного типа не рекомендуется использовать конструкцию "В (&СписокЗначений)", если при этом в списке присутствуют значения различных типов. Поскольку в этом случае, при выполнении запроса не задействуются индексы, из-за чего время выполнения может значительно увеличиться. Эффективнее выполнять объединение (с помощью "ОБЪЕДИНИТЬ ВСЕ") отдельных запросов для каждого значения из данного списка.

Неправильно:

Правильно:

В примере предполагается, что СписокОбъектов содержит значения типа
СправочникСсылка.Контрагент и СправочникСсылка.КонтактноеЛицо.

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

Оформление текстов запросов

1. Все ключевые слова языка запросов пишутся заглавными буквами.

2. Необязательные конструкции запроса желательно указывать в целях повышения наглядности текста запроса и «устойчивости» использующего его кода.
Например,
Если в алгоритме используется запрос с полем, объявленным как

при изменении имени реквизита нужно будет также изменить и код, осуществляющий обращение по имени свойства Валюта к выборке из результата запроса. Если же поле будет объявлено как

то изменение имени реквизита приведет только к изменению текста запроса.

3. Особенно внимательно следует относиться к автоматически присваиваемым псевдонимам для полей – реквизитов других полей, типа Касса.Валюта.Наименование. В приведенном выше примере поле получит автоматический псевдоним ВалютаНаименование, а не Наименование.

4. Некоторые из необязательных конструкций в текстах запросов должны указываться обязательно:
- ключевое слово КАК перед псевдонимом поля, источника.

5. Текст запроса должен быть структурирован, не следует писать запрос в одну строку, даже короткий. Вообще следует уделить достаточное внимание наглядности текста запроса, поскольку это существенно улучшает его понимание другими разработчиками.
В тех случаях, когда текст запроса составляется из нескольких частей в модуле, также рекомендуется придерживаться этого правила.

6. В запросы, сложные для понимания, в которых используются вложенные запросы, объединения или соединения обязательно необходимо вставлять комментарии. Комментарии должны объяснять для получения каких данных используется та или иная таблица в соединении или объединении.

7. При создании объекта Запрос следует указывать пользовательские комментарии, для получения какой информации или других целей будет использован данный запрос.

8. При программном "собирании" текста запроса необходимо комментировать все этапы его сборки.

9. При установке параметров запроса необходимо описывать, для каких целей передаются в запрос параметры.

10. Необходимо использовать синонимы полей запросов, в тех случаях, когда имя поля запроса не следует явно из имени поля таблицы. Другими словами не допускается автоматическая генерация имени поля, кроме явных случаев.
Так же не допускается автоматическая генерация имени поля типа «Номенклатура1», т.е. когда имя поля запроса не уникально ему тоже обязательно следует присвоить синоним.

Конструирование запросов

Выбрать
Не рекомендуется получать представление объекта ссылочного типа преобразованием ссылки к строке.
Если для объекта ссылочного типа планируется использовать его строковое представление (например, для визуализации в отчетах и элементах управления), в запросе следует выбирать предопределенное поле Представление, которое является готовым строковым представлением объекта ссылочного типа.

Из
1. В операторе ПО следует использовать внутреннее соединение с условием вместо использования двух таблиц с условием в предложении ГДЕ.
Неправильно:

Правильно: