Правила запроса. Выдержки из книги "Настольная книга 1С:Эксперта по технологическим вопросам"

17.06.19

Правила запроса, которые описаны в книге "Настольная книга 1С:Эксперта по технологическим вопросам". Актуальность темы связана с тем, что современные программисты не очень любят читать и даже не знакомы с этими рекомендациями.

При написании запросов могут быть допущены методические ошибки. Ниже перечислены правила, которых следует придерживаться. Большинство из них надо соблюдать всегда, вырабатывая правильный стиль написания кода. Однако есть правила, соблюдение которых требуется только при переписывании проблемных запросов (почему — станет ясно при ознакомлении с правилами), и для таких случаев в списке указано: «При возникновении проблем на данном участке кода».

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

2.Понимать, что запрос через объектную модель может не соответствовать правилу: Зафиксирован случай, когда при получении ДокументСсылка.Проведен из базы на самом деле запрашивались все реквизиты документа. Один из реквизитов имел тип ХранилищеЗначения и большой размер данных в хранилище, поэтому запрос ДокументСсылка.Проведен выполнялся очень долго. Обычно, однако, это не мешает работе, но при возникновении проблем на данном участке кода надо писать запросы на языке запросов, а не пользоваться объектной моделью.

Пояснения

В данном случае имеется в виду не ошибка платформы, как заметили читатели, а следующая структура:

СсылкаНаДокумент  = Документы.ЗаказПокупателя.НайтиПоКоду("0000000");
СсылкаНаДокумент.Контрагент // В данном случае тянутся все реквизиты объекта

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

3.При работе в автоматическом режиме блокировок при использовании конструкции ДЛЯ ИЗМЕНЕНИЯ надо указывать, какие таблицы блокировать, если в запросе участвует больше одной таблицы.

Пояснения

4.Условия в запросе и индексы в базе должны друг другу соответствовать (при возникновении проблем на данном участке кода).

Пояснения

Пояснение к правилу 4 (соответствие индексов и условий запроса)

Рекомендации.

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

Условия используются в следующих секциях запроса:

ВЫБРАТЬ... ИЗ... ГДЕ <условие>
СОЕДИНЕНИЕ... ПО <усповие>
ВЫБРАТЬ... ИЗ <ВиртуальнаяТаблица>(, <условие>)
ИМЕЮЩИЕ <условие>

Для каждого условия должен существовать подходящий индекс. Подходящим является индекс, удовлетворяющий следующим требованиям:

1.Индекс содержит все поля, перечисленные в условии;

2.Эти поля находятся в самом начале индекса;

3.Эти поля идут подряд, то есть между ними не «вклиниваются» поля, не участвующие в условии запроса;

При создании объекта метаданных «1С:Предприятие» автоматически создает индексы, которые должны подходить для работы большинства запросов.

Основные индексы, создаваемые «1С:Предприятием»:

индекс по уникальному идентификатору (ссылке) для всех объектных сущностей (справочники, документы и т. д.);

индекс по регистратору (ссылке на документ) для таблиц движений регистров, подчиненных регистратору;

индекс периоду и значениям всех измерений для итоговых таблиц регистров накопления;

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

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

Следует иметь в виду, что создание индекса ускоряет процесс поиска информации, но может несколько замедлить процесс ее изменения (добавления, редактирования и Удаления). Поэтому индексы следует создавать осознанно и только в том случае, если точно известен запрос, для которого такой индекс необходим. Не следует создавать индексы «на всякий случай» или заведомо избыточные индексы. Например, никогда не следует дополнительно индексировать первое измерение регистра, поскольку для поиска по значению первого измерения подходит основной индекс таблицы итогов, который автоматически создаст платформа.

Если в структуре базы данных отсутствует индекс, удовлетворяющий всем перечисленным условиям, то для получения результата СУБД будет вынуждена сканировать таблицу или один из ее индексов. Это приведет к увеличению времени выполнения запроса, а также к возможному снижению параллельности системы, поскольку возрастет количество установленных блокировок.

Требования к индексу, перечисленные в рекомендациях, связаны с физической структурой индекса в СУБД. Эта структура представляет собой дерево значений проиндексированных полей. На первом уровне дерева находятся значения первого поля индекса, на втором — второго и так далее. Такая структура позволяет достичь высокой эффективности при поиске по индексу. Кроме того, она гарантирует отсутствие деградации производительности индекса с ростом количества данных.

Однако, индекс такой структуры, очевидно, может быть использован только строго определенным образом. Сначала необходимо провести поиск по значению первого поля индекса, затем — второго и так далее. Если, например, условие по первому полю индекса не указано, то индекс уже не сможет обеспечить быстрый поиск. Если указано условие по нескольким первым полям индекса, а затем одно или несколько полей индекса не задано, то индекс может быть использован только частично.

5.При работе с виртуальными таблицами нужно использовать параметры виртуальных таблиц, а не выносить условия в секцию ГДЕ.

Дополнение от ogoneksergei

6.Не применять избыточное агрегирование, механизм виртуальных таблиц сам считает сумму, и так, как в примере, делать не надо:

СУММА(Остатки.СУММАВзаиморасчетовОстаток) КАК СуммаВзаиморасчетовОстаток

7.При соединении таблиц все условия и параметры, относящиеся к полям этих таблиц, ставить в условия соединения или пользоваться временными таблицами, а не оставлять их до секции ГДЕ. При этом, конечно, не должна страдать логика.

8.Не использовать подзапросы в условии соединения и в секции ГДЕ. Нужно использовать временные таблицы.

9. Вообще лучше не использовать соединения с подзапросами, а использовать временные таблицы.

Пояснения

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

При написании запросов не следует использовать соединения с подзапросами.

Следует соединять друг с другом только объекты метаданных или временные таблицы. Если запрос использует соединения с подзапросами, то его следует переписать с использованием временных таблиц.

Если запрос содержит соединения с подзапросами, то это может привести к следующим негативным последствиям:

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

Нестабильная работа запроса. При некоторых условиях запрос может работать достаточно быстро, при других — очень медленно.

Значительная разница по времени выполнения запроса на разных СУБД.

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

Пример потенциально опасного запроса, использующего соединение с подзапросом:

ВЫБРАТЬ ...ИЗ Документ.РеализацияТоваровУслуг
ЛЕВОЕ СОЕДИНЕНИЕ(
ВЫБРАТЬ ИЗ РегистрСведений.Лимиты
ГДЕ...
СГРУППИРОВАТЬ ПО...
) ПО...

В данном примере в правой части соединения используется подзапрос, а не объект метаданных. Обратите внимание на то, что в какой части соединения (правой или левой) используется подзапрос — не важно. Точно так же не важно, какого типа соединение указано (ЛЕВОЕ, ПРАВОЕ и т.д.). Во всех случаях такая конструкция является потенциально опасной и должна быть исправлена при помощи временных таблиц.

Обратите внимание на то, что возможность использования временных таблиц появилась в «1С:Предприятии» начиная с версии 8.1. Если вы используете версию 8.0, то для решения проблемы производительности такого запроса следует перейти на 8.1.

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

ВНИМАНИЕ!

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

Для вышеприведенного примера получится следующий пакетный запрос:

// Создать менеджер временных таблиц
МенеджерВТ = Новый МенеджерВременныхТаблиц;
Запрос = Новый Запрос;
Запрос.МенеджерВременныхТаблиц = МенеджерВТ;
// Текст пакетного запроса
Запрос.Текст = "
// Заполняем временную таблицу. Запрос к регистру лимитов.
| ВЫБРАТЬ...
| ПОМЕСТИТЬ Лимиты | ИЗ РегистрСведений.Лимиты
| ГДЕ...
| СГРУППИРОВАТЬ ПО...
| ИНДЕКСИРОВАТЬ ПО...;
// Выполняем основной запрос с использованием временной таблицы
ВЫБРАТЬ...
ИЗ Документ.РеализацияТоваровУслуг
ЛЕВОЕ СОЕДИНЕНИЕ Лимиты
ПО...;“

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

10.Не соединять виртуальные таблицы с реальными, а также виртуальные с виртуальными. Правильно сначала результат виртуальной таблицы записывать во временную таблицу, индексировать ее по полям соединения, а затем уже соединять. К данному правилу имеется оговорка. Использование индексации полей временной таблицы не всегда приводит к улучшению производительности. Будьте внимательны, применяя индексацию Вы можете увеличить время выполнения запроса

Пояснения

Пояснение к правилу 10 (не соединять виртуальные таблицы с реальными, а также виртуальные с виртуальными)

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

Как и в случае соединения с подзапросами, не имеет значения, какого типа соединение указано (ЛЕВОЕ, ПРАВОЕ и т. д.)

Если запрос работает с неудовлетворительной производительностью и в нем используется соединение с виртуальной таблицей языка запросов «1С:Предприятия»

(например, «РегистрНакопления.РасчетыСКлиентами.Остатки»), то рекомендуется вынести обращение к виртуальной таблице в отдельный запрос с сохранением результатов во временной таблице.

Пример, как это сделать, см. пояснение выше. Ниже приводится порядок действий, удобный при работе с конструктором и позволяющий избежать ошибок по невнимательности.

При работе в конструкторе запросов исправления удобно вносить следующим способом:

Исходный запрос:

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

Открываем запрос конструктором, на закладке Пакет запросов создаем запрос копированием существующего

В запросе «Запрос пакета 1» (т. е. в верхнем из двух) переходим на закладку Дополнительно, в поле «Тип запроса» выбираем «Создание временной таблицы» и указываем ее имя (см. рис. 4.20.1). После этого «Запрос пакета 1» станет называться по имени временной таблицы (в нашем случае ВТ_РасчетыСКлиентамиОстатки).

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

Затем на вкладке Таблицы и поля убираем все таблицы, кроме виртуальной таблицы РасчетыСКлиентами.Остатки, и добавляем поля, использующиеся в условии соединения, при этом может потребоваться ограничивать тип оператором ВЫРАЗИТЬ . На вкладке Индекс по этим полям индексируем временную таблицу.

Переходим на запрос пакета 2.

Па вкладке Таблицы и поля заменяем виртуальную таблицу на временную (см. рис.)

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

ВЫБРАТЬ
РасчетыСКлиентамиОстатки.СуммаОстаток КАК СуммаОстаток,
ВЫРАЗИТЬ(РасчетыСКлиентамиОстатки.ЗаказКлиента КАК Документ.ЗаказПациента) КАК ЗаказКлиента
ПОМЕСТИТЬ ВТ_РасчетыСКлиентамиОстатки
ИЗ
РегистрНакопления.РасчетыСКлиентами.Остатки(, ЗаказКлиента = &ЗаказКпиента) КАК РасчетыСКлиентамиОстатки
ИНДЕКСИРОВАТЬ ПО
ЗаказКлиента
;
////////////////////////////////////////////////
ВЫБРАТЬ
ЗаказПациента.Ответственный,
ВТ_РасчетыСКпиентамиОстатки.СуммаОстаток
ИЗ
Документ.ЗаказПациента КАК ЗаказПациента
ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ_РасчетыСКлиентамиОстатки КАК ВТ_РасчетыСКлиентамиОстатки
ПО (ВТ_РасчетыСКлиентамиОстатки.ЗаказКлиента = ЗаказПациента.Ссылка)

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

12.Аналогично с условием «Не равно», особенно если на «Не равно» сравниваются ссылки (при возникновении проблем на данном участке кода).

13.В секции ГДЕ логическое ИЛИ использовать тоже не рекомендуется. Следует разбить один запрос на несколько и объединить результаты (при возникновении проблем на данном участке кода).

14.Избегать запросов к пустым таблицам в режиме автоматического управления блокировками 1С.

15.Аккуратно пользоваться разыменованием (получением данных «через точку»):

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

ПО ФИО.ФизЛицо = ФизЛица.Ссылка

а не

ПО ФИО.ФизЛицо.Наименование = ФизЛица.Ссылка.Наименование

Не получать еще раз Ссылка

ПО ФИО.ФизЛицо = ФизЛица.Ссылка

а не

ПО ФИО.ФизЛицо.Ссылка = ФизЛица.Ссылка

Никогда не использовать конструкцию Ссылка.Ссылка. Это всегда ошибка

Пояснения

Если в запросе используется получение значения через точку от поля составного ссылочного типа, то при выполнении этого запроса будет выполняться соединение со всеми таблицами объектов, входящими в этот составной тип. В результате SQL текст запроса чрезвычайно усложняется, и при его выполнении оптимизатор СУБД может выбрать неоптимальный план. Это может привести к серьезным проблемам производительности и даже к неработоспособности запроса в отдельных случаях.

В частности, не рекомендуется обращаться к реквизитам регистратора регистра (например, ТоварыНаСкладах.Регистратор.Дата) и т. п. При этом неважно, в какой части запроса вы используете реквизит, полученный через точку от поля составного типа — в списке возвращаемых полей, в условии и т.п. Во всех случаях такое обращение может привести к проблемам производительности.

Общая рекомендация заключается в том, чтобы по возможности ограничить количество соединений в таких запросах. Для этого можно использовать следующие приемы:

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

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

При необходимости жертвуйте компактностью и универсальностью кода ради производительности. Как правило, для выполнения конкретного запроса в данных условиях не нужны все возможные типы данной ссылки. В этом случае, следует ограничить количество возможных типов при помощи функции ВЫРАЗИТЬ. Если данный запрос является универсальным и используется в нескольких разных ситуациях (где типы ссылки могут быть разными), то можно формировать запрос динамически, подставляя в функцию ВЫРАЗИТЬ тот тип, который необходим при данных условиях. Это увеличит объем исходного кода и, возможно, сделает его менее универсальным, но может существенно повысить производительность и стабильность работы запроса.

Вступайте в нашу телеграмм-группу Инфостарт

Правила запросы

+96 –1

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

0% комиссии — оплата напрямую исполнителю;
Исполнители любого масштаба — от отдельных специалистов до команд под проект;
Прямой обмен контактами между заказчиком и исполнителем;
Безопасная сделка — при необходимости;
Рейтинги, кейсы и прозрачная система откликов.

См. также

Infostart Toolkit Air: Инструменты разработки в 1С:8.3 и 8.5

Инструментарий разработчика Роли и права Запросы СКД Разработчик Руководитель проекта 1С:Предприятие 8 Платные (руб)

Инструменты для разработчиков 1С 8.3 и 8.5: Infostart Toolkit. Автоматизация и ускорение разработки на управляемых формах. Легкость работы с 1С.

16500 руб.

02.09.2020 285543 1606 423

1220

Графическое представление текста запроса

Инструментарий разработчика Запросы Разработчик 1С 8.3 1С:Бухгалтерия 3.0 1С:Зарплата и Управление Персоналом 3.x Абонемент ($m)

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

2 стартмани

06.07.2026 4940 65 XSlava 20

Конструктор запросов 1С прямо в VS Code — без Конфигуратора и EDT

Запросы Разработчик 1С 8.3 Россия Бесплатно (free)

Визуальный «Конструктор запроса» 1С, встроенный прямо в VS Code, — аналог конструктора из Конфигуратора и EDT, но без запуска платформы. Расширение читает конфигурацию, выгруженную в файлы, позволяет собрать запрос мышью и генерирует корректный текст на языке запросов 1С (SDBL). Открывает уже существующий текст запроса из кода для правки и — что особенно ценно — сохраняет комментарии при цикле «открыть - править - сохранить». Подходит тем, кто пишет код 1С в VS Code, держит под рукой множество проектов и не хочет ради одного запроса запускать тяжёлый Конфигуратор или EDT.

26.06.2026 10656 Alex_YAM 7

Нейроконсоли запросов 1.0 DeepSeek и 2.0 DeepSeek + Claude. (с метаданными конфигурации)

Нейросети Инструментарий разработчика Запросы Разработчик 1С:Предприятие 8 Абонемент ($m)

Консоль запросов 1.0: добавлен ИИ-помощник (запрос в DeepSeek), который помогает быстрее получать каркас Запроса 1С Сформулируйте простое описание; нажмите кнопку – получите результат прямо в консоли. Где дальше его можно дорабатывать и тестировать. 28.5.2026 Добавил "Консоль запросов 2.0" (запрос в DeepSeek + Claude) 4.10.2026 Обновил "Консоль запросов 2.0"

3 стартмани

20.05.2026 9560 46 German4739 72

Post1С - аналог Postman на платформе 1С

WEB-интеграция Запросы Разработчик 1С 8.3 Абонемент ($m)

Post1C - это внешняя обработка, которая превращает 1С в полноценный инструмент для тестирования REST API. Всё управление сосредоточено в одном окне: настройка запроса, выполнение, просмотр ответа и генерация кода - без переключения между формами. Аналог Postman, но работающий в привычной среде 1С.

1 стартмани

02.04.2026 4635 105 priem_nv 27

Модификация запросов по схеме запроса типовыми возможностями УТ 11.5, о которых вы не знали

Запросы Механизмы типовых конфигураций Разработчик 1С:Предприятие 8 1С:Управление торговлей 11 Россия Бесплатно (free)

Предлагается обзор работы с объектной моделью запроса по схемам запросов типовым функционалом УТ 11.5.

09.10.2025 13394 aximo 18

Консоль запросов ЗУП с поддержкой обращения к методам программного интерфейса в запросах

Инструментарий разработчика Запросы Разработчик 1С:Предприятие 8 1С:Зарплата и кадры государственного учреждения 3 1С:Зарплата и Управление Персоналом 3.x Абонемент ($m)

QueryConsole1C — расширение, включающее консоль запросов с поддержкой исполняемых представлений — аналогов виртуальных таблиц, основанных на методах программного интерфейса ЗУП. Оно позволяет выполнять запросы с учётом встроенной бизнес-логики, отлаживать алгоритмы получения данных и автоматически генерировать код на встроенном языке 1С.

1 стартмани

16.05.2025 13655 168 zup_dev 32

Семерых одним ударом: ищем все ошибки в запросе за один раз!

Инструментарий разработчика Запросы Разработчик 1С:Предприятие 8 1С:ERP Управление предприятием 2 Абонемент ($m)

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

2 стартмани

05.03.2025 7712 25 XilDen 12

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. Rashid80 33 18.06.19 09:14 Сейчас в теме

Есть ряд замечаний.

2. Нельзя писать код с учетом косяка конкретной версии платформы. Так же не раскрыто правило на которое ссылается абцаз.
4. От запроса до плана запроса в SQL-базе пройдет много шагов, включая оптимизацию (упорядочивание условий по существующим индексам). Кроме того для выборки используются не только индексы, но и статистика - все это нелинейно. Совет может вселить ложную уверенность.
9. Неоднократно оптимизировал куски функцию путем убирания временных таблиц в пользу подзапроса. Получалось существенно быстрее.
10. Индексирование по полям временной таблицы - не серебряная пуля. Особенно есть ВТ используется в запросе один раз.

Ответить

3. Lucifer93 100 18.06.19 09:28 Сейчас в теме

(1) По поводу второго пункта сейчас поработаю подробнее.
4. С 4 не могу согласиться, так как при создании объектов конфигурации в SQL базе создаются индексы поиск по которым, независимо от статистики будет происходить быстрее, исходя из документации к SQL. Поэтому выборка по индексам изначально выполняется быстрее. Под статистикой Вы подразумеваете оптимизацию запроса средствами SQL? Если да, то независимо от набранной статистики запрос по индексам выполняется быстрее.
9. Я лишь единожды встречал, чтобы подзапрос работал быстрее временной таблицы. В данном случае я посчитал это исключением из правил и не стал делать на это акцент.
10. Тут, пожалуй, нужно сделать оговорку, что в некоторых случаях лучше индексировать. Поправлю статью, как только появится свободное время.

5. Lucifer93 100 18.06.19 09:41 Сейчас в теме

(3) Пункт 2 добавил свои пояснения по поводу получения реквизитов через точку.

7. alalsl 13 18.06.19 09:49 Сейчас в теме

(3) Не единожды видел, что подзапросы быстрее работают
Но использую временные таблицы)
На инфостарте уже писалось, что временные таблицы не панацея

8. Lucifer93 100 18.06.19 09:51 Сейчас в теме

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

9. alalsl 13 18.06.19 09:54 Сейчас в теме

(8) Согласен. Для меня преимущество временных таблиц их удобочитаемость

46. echo77 1944 19.06.19 11:29 Сейчас в теме

(1)
п. 2 Это из стандартов разработки 1С https://bit.ly/2Ro7X2a

2. ixijixi 2177 18.06.19 09:22 Сейчас в теме

А где пункт №3?

4. Lucifer93 100 18.06.19 09:32 Сейчас в теме

(2) В данный момент его добавляю, каким-то чудом он решил не отображаться

6. Lucifer93 100 18.06.19 09:41 Сейчас в теме

(4) Пункт 3 добавлен с пояснениями автора

10. HAMMER_59 257 18.06.19 11:16 Сейчас в теме

Берем запрос с виртуальной таблицей периодического регистра сведений. Переносим условия из секции где в параметры виртуальной таблицы, убеждаемся что результат запроса теперь совсем другой. Делаем выводы.

12. Lucifer93 100 18.06.19 11:35 Сейчас в теме

(10) Не могу понять о чем Вы, хотелось бы пример увидеть. Что именно меняется в результате?

11. ogoneksergei 3 18.06.19 11:19 Сейчас в теме

5. Не относится в срезам последних/первых Регистров сведений. Так как использование параметров виртуальной таблицы могут дать не тот результат который нужен.

13. Lucifer93 100 18.06.19 11:35 Сейчас в теме

(11) Не могу понять о чем Вы, хотелось бы пример увидеть. Что именно меняется в результате?

14. ogoneksergei 3 18.06.19 11:55 Сейчас в теме

(13)Пример
Кадровый учет.
Регистр сведений кадровой истории.
ПЕРИОД СОТРУДНИК ВИД ДЕЙСТВИЯ
01.01.2019 Иванов Прием
01.01.2019 Петров Прием
01.05.2019 Иванов Увольнение

При выборке среза последних на 01.06.2019 если условие запроса ВидДействия = Прием установить в параметры ВТ то в результате будут две строки от 01.01.2019 так как условие будет выполняться при формировании ВТ среза последних. В результате на 01.06.2019 попадет Иванов который уволен 01.05.2019.

А если это условие вынести в ГДЕ то сначала в ВТ выберутся строки 01.01.2019 Петров и 01.05.2019 Иванов, а затем сработает отбор и в результате останется только Петров который реально принят на 01.06.2019.

Ответить

16. Lucifer93 100 18.06.19 12:43 Сейчас в теме

(14) Согласен, в данном случае условие отрабатывает некорректно. Подправлю сейчас статью

29. ogoneksergei 3 18.06.19 14:55 Сейчас в теме

(16) Я думаю что условие отрабатывает корректно. Просто нужно понимать правильное применение условий в виртуальных таблицах.

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

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

Применительно к моему примеру.

В первом варианте выборка делается с учетом условия в параметрах виртуальной таблицы ВидДействия - Прием. т.е. результат ВТ до выборки последних уже равен первым двум строкам.
01.01.2019 Иванов Прием
01.01.2019 Петров Прием

А во втором случае выбираются последние записи по измерениям.
01.01.2019 Иванов Прием
01.05.2019 Иванов Увольнение
Затем срабатывает условие ВидДействия - Прием и вторая строка исключается.

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

15. HAMMER_59 257 18.06.19 12:09 Сейчас в теме

(13) Пример вам уже привели в 14 комментарии. Могу только добавить, что как только мы перенесем условие в параметры виртуальной таблицы периодического регистра сведений, у нас еще и скорость выполнения резко упадет, т.к. без указания даты мы просто получали таблицу последних значений, например, по ценам, которая относительна небольшая, а как только перенесли отбор в параметры виртуальной таблицы начинается перебор всей таблицы регистра, и таблица эта может быть очень не маленькой, например, еженедельная таблица цен поставщиков.

19. Lucifer93 100 18.06.19 12:49 Сейчас в теме

(15) Дописал в статью пример 14! Спасибо за объяснения!

62. Monte Carlo 21.06.19 15:58 Сейчас в теме

(15)

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

Недавно где-то в статье тут на инфостарте увидел, что Период в периодическом регистре сведений в платформе 8.3 стоит после измерений в индексе, так что непонятно почему должна производительность упасть.

17. AlexPC 18.06.19 12:44 Сейчас в теме

6. Не очень понятен пункт, можете подробнее написать про механизм виртуальных таблиц, который сам считает сумму?

18. Lucifer93 100 18.06.19 12:47 Сейчас в теме

(17) Тут идет речь о том, что в регистре изначально хранится СУММАвзаиморасчетов и в запросе мы пытаемся ее просуммировать повторно.

23. AlexPC 18.06.19 13:10 Сейчас в теме

(18) Эээ ... допустим, а если мне нужна более крупная аналитика, что же теперь - не суммировать?

24. AlexPC 18.06.19 13:16 Сейчас в теме

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

20. VmvLer 18.06.19 12:53 Сейчас в теме

я так понимаю в этот статье готовят выпуск 2-ой части бестселлера?
или тут кружок по интересам "все лгут"?

21. Lucifer93 100 18.06.19 13:01 Сейчас в теме

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

22. VmvLer 18.06.19 13:08 Сейчас в теме

(21) а чем сейчас занят сам автор, считает ракушки на Бали?

даже если это так, то пусть считает, но зачем делать работу за кого-то,
мы, наконец, пришли к коммунизму?

25. Lucifer93 100 18.06.19 13:19 Сейчас в теме

(22) Как минимум для того, чтобы программисты 1с писали качественные запросы. Например у меня в компании нет и не было человека, который мог бы мне объяснить правила запроса, стандарты разработки и прочее. Мне приходилось сидеть и читать книги, а оказалось так, что в данных книгах тоже есть неточности. Я очень рад, что сообщество столь активно проявило интерес к статье и сделать лучше одну из немногочисленных книг по 1с было бы здорово!

26. Lucifer93 100 18.06.19 13:22 Сейчас в теме

(25) Да и вообще было бы круто создать универсальные правила запросов, которые одобрило бы сообщество 1с.

27. VmvLer 18.06.19 13:30 Сейчас в теме

(26) Открою вам секрет - во вселенной и нашем маленьком мирке в частности нет и не может быть ничего универсального.

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

28. Lucifer93 100 18.06.19 13:38 Сейчас в теме

(27) Пожалуй, я с Вами не соглашусь. Не хочу спорить отдаляясь от темы.

58. Sergey.Noskov 1434 19.06.19 15:30 Сейчас в теме

(28) напрасно)) Универсальные правила это когда не обязательно разбираться в вопросе. Они не нужны, когда есть понимает как работает СУБД, как влияете архитектура решения и сложность самого запроса, как посмотреть план выполнения, как определить самую ресурсоёмкую операцию запроса и почему именно так происходит.

30. AlexPC 18.06.19 15:52 Сейчас в теме

(27)

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

А еще теория далека от практики :) Взять например те же нормальные формы из теории БД.

49. Yashazz 4930 19.06.19 13:01 Сейчас в теме

(30) А ещё забывается, что запросы лишь получающая сторона, а есть ещё хранящая, т.е. архитектура. И под "универсальные правила запросов" пришлось бы сначала придумать "универсальную концепцию хранения данных". Один и тот же подход имеет разную эффективность в зависимости от структур и связей таблиц.

48. Yashazz 4930 19.06.19 12:58 Сейчас в теме

(25) Да уж, "неточности". В первой редакции 1С-Эксперта была пара таких "неточностей", особенно касательно блокировок, которые стоили мне проваленного экзамена по эксперту.

32. Bassgood 1509 18.06.19 22:53 Сейчас в теме

(22) Не все же в этом мире делать только ради личной материальной выгоды, у человека помимо этого есть еще и такие нематериальные (по крайней мере до определенного момента времени) потребности как "стремление к развитию", "признание в проф. сообществе", "помощи другим людям" и т.д., которые в будущем собственно и приводят человека на более высокие ступени успеха, нежели многих других его коллег, которые считают подобную деятельность за "вот делать то нефига людям" и предпочитают вместо этого потратить время "на себя любимого".
p.s. Кто знает, возможно после получения автором книги этих дополнений - автора статьи пригласят из обыденной компании на интересную ему работу в фирму "1С" с кратным повышением оклада, а далее возможно поднимется и до уровня руководителя какого-нибудь отдела. Да и приятно будет видеть свои дополнения в книге, выпускаемой под редакцией фирмы "1С" - это также и очень хорошая рекомендация для потенциальных работодателей автора статьи (тем более в книге, касающейся производительности систем 1С, специалистов которых на рынке и так "раз, два и обсчитался")

35. VmvLer 19.06.19 09:18 Сейчас в теме

(32) Я думаю, что 99% копи-паста чужих мыслей и 1% своих в стартовом сообщении это именно

только ради личной материальной выгоды

а крайняя категоричность

что современные программисты не очень любят читать и даже не знакомы с этими рекомендациями.

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

Причем, идей от автора так и не поступило. Посему говорить о том, что из него выйдет что-то путное, в контексте профессионализма, преждевременно.

Ответить

36. Lucifer93 100 19.06.19 09:25 Сейчас в теме

(35) Простите, а какую личную материальную выгоду я имею? Еще одним интересным фактом является то, что никаких идей я целенаправленно не вносил, так как пытаюсь познакомить общественность с уже имеющимися идеями автора. Считаю, что в (32) автор больше фантазирует о возможном профессионализме недели говорит об этом серьезно.
Вам не стоит пытаться увидеть в людях только плохое.

37. VmvLer 19.06.19 09:32 Сейчас в теме

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

40. Lucifer93 100 19.06.19 09:52 Сейчас в теме

(37) Эта статья является результатом спора на инфостарте, в котором разработчики доказывали, что использование ИЛИ в условиях является нормальным. Ссылаясь на автора книги я приводил аргументы, что это не так. Оказалось, что у многих не хватает времени на чтение, не доходят руки и тд. Отсюда желание выявить основные идеи автора и представить их в короткой статье.

43. VmvLer 19.06.19 10:29 Сейчас в теме

(40) Ссылаться на кого-то, отстаивая свою картину мира сомнительная стратегия.
Ведь можно оперировать элементарной логикой и практикой без звоночков из детства: "А вот Марь Ивановна сказала, что так нельзя..."

ИЛИ - это ключевое слово языка запросов и его использование является нормальным без всяких доказательств.

А вот вопрос эффективности использования ИЛИ зависит от множества факторов и диспут по этому поводу мне напоминает кваканье жаб, каждая из которых хвалит свое болото.

44. Lucifer93 100 19.06.19 10:48 Сейчас в теме

(43)
(43)
Ссылаться на человека, который знает явно больше моего в 1с, считаю вполне нормальным. Вообще, применять рекомендации, которые написаны в рамках методической поддержки пользователю является хорошим тоном.
"ИЛИ - это ключевое слово языка запросов и его использование является нормальным без всяких доказательств." Только вот как раз об этом и говорится, что не всегда это является нормальным. В большинстве случаев это несет потерю производительности.
То, что Вы называете "практикой без звоночков из детства" в научных кругах называется "ссылка на авторитетный источник".

51. Yashazz 4930 19.06.19 13:04 Сейчас в теме

(40) Это не тянет ни на квинтэссенцию, ни даже на дайджест. Если вам приходится разъяснять, чем для среза регистра сведений отличается параметр в виртуалке от условия "где", то - ну у меня вопросов нету.

55. Lucifer93 100 19.06.19 13:19 Сейчас в теме

(51)
(51) Не вижу ничего зазорного чего-то не знать. Это дайджест - "публикация наиболее интересных материалов из разных областей знаний, появившиеся в печати в последнее время". В данном случае я на тематическом портале делаю выдержку наиболее интересных материалов в определенной области.
По поводу "не знания" Вы так и не ответили мне на свой комментарий (31) в котором указали, что ВЫБОР КОГДА тоже условие по которому накладывается индекс, хотя практика показывает, что это не так.

50. Yashazz 4930 19.06.19 13:02 Сейчас в теме

(36) Как это "какую личную выгоду"? Вы скопипастили чужую книгу и теперь на этом сшибаете стартмани на Инфостарте.

56. Lucifer93 100 19.06.19 13:22 Сейчас в теме

(50) Пожалуй, в данном случае Вы правы. Я действительно получил стартмани за данную публикацию, но в этом и нет ничего плохого, как Вы могли заметить данная статья сумела заработать 37 добавлений в избранное, что доказывает ее полезность. Если для Вас она оказалась бесполезной Вы могли пройти дальше.

63. Yashazz 4930 21.06.19 19:55 Сейчас в теме

(56) Это доказывает, что репост с нарушением авторских прав, защищаемых, между прочим, фирмой 1С, пользуется спросом. И что это в разы легче, чем сделать действительно свою самостоятельную публикацию.

Интересна позиция администрации ИС, потому как, напомню, "полное или частичное копирование материалов книги без письменного разрешения фирмы "1С-Паблишинг" запрещается". У вас есть такое разрешение?)

А так да, следуя вашей логике, и в воровстве ничего плохого нет - ворованное многие охотно скупают и пользуются)

31. Yashazz 4930 18.06.19 21:00 Сейчас в теме

Это вчистую передрано из Филиппова, или есть что-то своё?

Потому что, например, в п.4 совершенно не освещена такая прелесть, как ВЫБОР КОГДА, а это тоже условие. И мне доводилось видеть феерическое несоответствие производительности в этой части казалось бы подходящим индексам СУБД.

33. Lucifer93 100 19.06.19 06:11 Сейчас в теме

(31) Все пункты являются цитатами Филиппова. Насколько я Вас понял, Вы имеете в виду, что на ВЫБОР КОГДА не накладывается индекс? Я нигде не встречал информацию, что ВЫБОР КОГДА является причиной отбора по индексу.

34. Lucifer93 100 19.06.19 08:15 Сейчас в теме

(31)
(31) Проверил на практике. По полям ВЫБОР КОГДА индекс не строится. Автор в 4 пункте раскрыл все имеющиеся поля для связи по индексам. Скорее всего, ВЫБОР КОГДА начинает работать после обращения к SQL базе. То есть, мы получаем результаты запроса из SQL и потом начинается перебор значений подходящих под условия ВЫБОР КОГДА.

38. herfis 525 19.06.19 09:40 Сейчас в теме

Зафиксирован случай

В "проф-разработке" об этом открытым текстом написано :)
4. Я бы сказал так - доп-индексы следует создавать только тогда, когда это действительно решает проблему производительности (зафиксирован реальный профит). Даже эффективные на первый взгляд индексы могут по факту оказываться неэффективными с точки зрения оптимизатора запросов и использоваться не будут.
9,10 - хорошо, что оговорки написали :) На том же MSSQL я практически не сталкивался с ситуациями, когда вынос подзапросов (особенно тяжелых) во временные таблицы улучшал производительность. когда ухудшало - сталкивался. Хотя тут, конечно, очень многое зависит от того, как именно используется подзапрос. Возможно, это особенность моего стиля написания запросов. Индексация временных таблиц тоже никогда не приводила к заметному улучшению производительности в моей практике. Опять же, речь про MSSQL и мою личную практику. При работе с Postgresql работа оптимизатора вызывала гораздо больше wtf. Он там судя по всему гораздо более "деревянный". Поэтому там разбиение запроса на этапы может быть оправдано, чтобы не давать оптимизатору много шансов на ошибку.

39. Lucifer93 100 19.06.19 09:48 Сейчас в теме

(38) Я в своей практике встречал несколько раз моменты, когда индексация ВТ повышала производительность. Насколько я помню, тут вопрос в количестве строк ВТ и уникальности значений.

41. herfis 525 19.06.19 10:22 Сейчас в теме

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

42. Lucifer93 100 19.06.19 10:27 Сейчас в теме

(41) Очень странно работает данный механизм. Надо будет заглянуть ему "под капот" и понять точные условия когда он эффективен. А то разговоров об этом получается много, а реальных данных нет.

45. herfis 525 19.06.19 11:19 Сейчас в теме

(42) Думаю, что проблема как раз в том, что точные условия будет вывести проблематично. Слишком много факторов из конкретного окружения влияют на выбор оптимального плана. Поэтому справедлива общая рекомендация - писать как проще, но без явных косяков а оптимизацией заниматься когда появляются узкие места.
Создание доп-индексов - это обычно уже оптимизация и она не бесплатна. Хотя бывают конечно случаи, когда уже на этапе проектирования необходимость доп-индекса совершенно очевидна. Ну, то есть заранее известно что таблица будет очень большая, условия по этому полю будут применяться в критичных по времени выполнения запросах, а индекс по этому полю будет иметь очень высокую селективность. Другими словами, оптимизатор этим индексом точно пренебрегать не станет.
(43) В статье же написано, что заморачиваться отказом от ИЛИ стоит только при решении задач оптимизации. И это вполне разумный совет. Потому что наличие ИЛИ сразу делает невозможным применение эффективных алгоритмов с использованием хэш-таблиц. И если переписать запрос, то вполне можно получить существенную оптимизацию. Или не получить, если бутылочное горлышко было в другом месте :)

53. Yashazz 4930 19.06.19 13:09 Сейчас в теме

(45) Если при проектировании необходимость доп.индекса очевидна, а подозрения в "деревянности" оптимизатора есть, можно вообще выкрутиться средствами 1С, т.е. грамотно организовать нужные таблицы, добавить пару регистров сведений или ещё чего, тогда и запрос станет проще, прозрачнее и однозначнее.

52. AlexPC 19.06.19 13:08 Сейчас в теме

(38)

На том же MSSQL я практически не сталкивался с ситуациями, когда вынос подзапросов (особенно тяжелых) во временные таблицы улучшал производительность. когда ухудшало - сталкивался

Я читал, что в MS SQL так и получается, то есть подзапросы обрабатываются как служебные временные таблицы, разве что индексирования там не происходит.

54. Yashazz 4930 19.06.19 13:10 Сейчас в теме

(52) А на момент выполнения "надзапроса" скуль уже знает статистику по подзапросу? Я раньше такого не замечал.

57. Rashid80 33 19.06.19 14:25 Сейчас в теме

(38)
У меня ровно те же наблюдения в части работы с MS SQL Server - чаще подзапросы работают быстрее чем ВТ. Ну и индексация ВТ в небольшом запросе чаще роняет перформанс.
Для постгрес могу сказать только одно - если можно не использовать его как сторадж для 1с, лучше не использовать.

60. Indgo 433 19.06.19 18:40 Сейчас в теме

(57)Подзапросы очень неудобно читать. К тому же можно вывести временные таблы на отдельный ссд массив и тогда разницы мало

47. Yashazz 4930 19.06.19 12:46 Сейчас в теме

Насчёт п.6 - ясное дело, речь лишь о "СУММА", т.к. никакие максимумы и средние механизм запроса по регистру для вас считать не станет, там только и именно суммирование.

59. slimper 201 19.06.19 16:24 Сейчас в теме

(0) Самоплюсование, зачем? Некрасиво.

61. s22 23 20.06.19 12:06 Сейчас в теме

8. не актуально для платформы 8.3.13 и выше без режима совместимости при Postgre 11

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

В режиме совместимости с версией 8.3.12 поведение не изменилось.
Источник: https://dl04.1c.ru/content/Platform/8_3_15_1469/1cv8upd_8_3_15_1469.htm#7946ee38-1178-11e8-a3f7-0050569f678a

Более того, изменилось дефолтное поведение. Теперь CTE-подзапрос по умолчанию будет инлайниться, если его результат используется один раз. В противном случае будет как раньше материализовываться.
https://habr.com/ru/post/440576/
Важные изменения в работе CTE в PostgreSQL 12

64. slayer-ekb 16 24.06.19 09:56 Сейчас в теме

Добавлю еще пункт про разыменование в запросе: при обращении через точку происходит разыменование полей, т.е. план запросов строит подзапрос. Речь идет о полях. для которых требуется разыменование, напр. Контрагент.Склад.Регион.
так же при выводе результатов запроса еще бывают моменты, когда платформа строит дополнительный запрос (например, когда требуется вывести пользователю информацию) для получения представления. Напр. при выводе сообщения типа .ссылка, платформа строит доп. запрос к субд для получения преставления ссылки. Конечно, это милисекунды в 3-4 знаке после запятой, но при больших числах и массовом работе, могут быть и задержки посерьезнее ))
Еще запросы в цикле - дебилизм, за который надо бить лопатой.

Еще неявные запросы в цикле, напр:
Для каждого стр из Товары цикл
стр.чтотам = стр.коечто.коегде.коекак;
КонецЦикла;

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

65. Quantum81 7 24.06.19 11:20 Сейчас в теме

Повторить перед собеседованием :)
Книжка у самого лежит, но мне кажется Бурмистров в своих курсов около 30 ти пунктов разбирал.

66. Artem-B 104 01.07.19 13:28 Сейчас в теме

Вы просто скопипастили в сокр. виде раздел из книги Филиппова и выложили на ИС? А чего, так можно было?

67. rusja 23.08.20 16:56 Сейчас в теме

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

Табличная часть документа содержит Номенклатуру и Количество. Запросом нужно получить таблицу, где кроме этих полей будет КоличествоОстаток. Остатки хранятся в регистре остатков с измерением Номенклатура и ресурсом Количество. Естественно первая мысль - делаем левое соединение по Номенклатуре:

без условия в параметрах виртуальной таблицы

"ВЫБРАТЬ
		|	ПродажаТоваровТовары.Номенклатура КАК Номенклатура,
		|	ПродажаТоваровТовары.Количество КАК Количество,
		|	ЕСТЬNULL(ОстаткиНоменклатурыОстатки.КоличествоОстаток, 0) КАК КоличествоОстаток
		|ИЗ
		|	Документ.ПродажаТоваров.Товары КАК ПродажаТоваровТовары
		|		ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ОстаткиНоменклатуры.Остатки(&ПозицияДокумента) КАК ОстаткиНоменклатурыОстатки
		|		ПО ПродажаТоваровТовары.Номенклатура = ОстаткиНоменклатурыОстатки.Номенклатура
		|ГДЕ
		|	ПродажаТоваровТовары.Ссылка = &Ссылка";[/spoiler]

Но вспоминаем, как важно использовать параметры виртуальной таблицы. В нашем случае напрашивается условие на наличие Номенклатуры регистра в списке Номенклатуры из табличной части. Однако для того, чтобы выполнить это требование приходится в параметры виртуальной таблицы вставлять вложенный запрос. А чтобы этот вложенный запрос не дублировал получение данных табличной части - напрашивается временная таблица. Вобщем получается что-то такое:

с условием в параметрах виртуальной таблицы
		[1C-CODE]"ВЫБРАТЬ
		|	ПродажаТоваровТовары.Номенклатура КАК Номенклатура,
		|	ПродажаТоваровТовары.Количество КАК Количество
		|ПОМЕСТИТЬ втТовары
		|ИЗ
		|	Документ.ПродажаТоваров.Товары КАК ПродажаТоваровТовары
		|ГДЕ
		|	ПродажаТоваровТовары.Ссылка = &Ссылка
		|
		|ИНДЕКСИРОВАТЬ ПО
		|	Номенклатура
		|;
		|
		|////////////////////////////////////////////////////////////////////////////////
		|ВЫБРАТЬ
		|	втТовары.Номенклатура КАК Номенклатура,
		|	втТовары.Количество КАК Количество,
		|	ЕСТЬNULL(ОстаткиНоменклатурыОстатки.КоличествоОстаток, 0) КАК КоличествоОстаток
		|ИЗ
		|	втТовары КАК втТовары
		|		ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ОстаткиНоменклатуры.Остатки(
		|				&ПозицияДокумента,
		|				Номенклатура В
		|					(ВЫБРАТЬ
		|						втТовары.Номенклатура КАК втТоварыНоменклатура
		|					ИЗ
		|						втТовары)) КАК ОстаткиНоменклатурыОстатки
		|		ПО втТовары.Номенклатура = ОстаткиНоменклатурыОстатки.Номенклатура";

Показать

Теперь в свете рекомендаций из статьи топика возникает желание уйти от соединения с виртуальной таблицей. Как следствие, временных таблиц в запросе становится аж две, и примитивный запрос превращается вот в такого переростка:

избавляемся от соединения с виртуальной таблицей

"ВЫБРАТЬ
		|	ПродажаТоваровТовары.Номенклатура КАК Номенклатура,
		|	ПродажаТоваровТовары.Количество КАК Количество
		|ПОМЕСТИТЬ втТовары
		|ИЗ
		|	Документ.ПродажаТоваров.Товары КАК ПродажаТоваровТовары
		|ГДЕ
		|	ПродажаТоваровТовары.Ссылка = &Ссылка
		|
		|ИНДЕКСИРОВАТЬ ПО
		|	Номенклатура
		|;
		|
		|////////////////////////////////////////////////////////////////////////////////
		|ВЫБРАТЬ
		|	ОстаткиНоменклатурыОстатки.Номенклатура КАК Номенклатура,
		|	ЕСТЬNULL(ОстаткиНоменклатурыОстатки.КоличествоОстаток, 0) КАК КоличествоОстаток
		|ПОМЕСТИТЬ втОстатки
		|ИЗ
		|	РегистрНакопления.ОстаткиНоменклатуры.Остатки(
		|			&ПозицияДокумента,
		|			Номенклатура В
		|				(ВЫБРАТЬ
		|					втТовары.Номенклатура КАК втТоварыНоменклатура
		|				ИЗ
		|					втТовары)) КАК ОстаткиНоменклатурыОстатки
		|
		|ИНДЕКСИРОВАТЬ ПО
		|	Номенклатура
		|;
		|
		|////////////////////////////////////////////////////////////////////////////////
		|ВЫБРАТЬ
		|	втТовары.Номенклатура КАК Номенклатура,
		|	втТовары.Количество КАК Количество,
		|	втОстатки.КоличествоОстаток КАК КоличествоОстаток
		|ИЗ
		|	втТовары КАК втТовары
		|		ЛЕВОЕ СОЕДИНЕНИЕ втОстатки КАК втОстатки
		|		ПО втТовары.Номенклатура = втОстатки.Номенклатура";

Показать

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

68. Metallic1 16.06.21 09:33 Сейчас в теме

(67)А собственно 3 запрос зачем?

72. YA_2330045004 10.07.26 12:29 Сейчас в теме

(67) Зачем в первой части запроса Номенклатуру и Количество из ТЧ помещать во временную таблицу? Перекладывание из ТЧ во временную таблицу ничего не даёт.
Во второй части запроса при указании параметров виртуальной таблицы можно обратиться подзапросом к ТЧ документа точно так же, как ко временной таблице.
В общем, я бы убрал втТовары.

73. YA_2330045004 11.07.26 14:42 Сейчас в теме

(72) Беру свои слова назад, показал похожий запрос наставнику и ответ был однозначным: и запрос к ТЧ документа, и виртуальную таблицу надо помещать во временные таблицы. Так что, вероятно, запрос-переросток - самый правильный вариант.

69. SergMuravev 954 11.07.23 00:42 Сейчас в теме

(0) 9 пункт. "Не забудьте проиндексировать временную таблицу!"
При левом соединении если временная таблица находится слева, индексировать ее не нужно. Все равно будет чтение всех записей таблицы.

70. ut2k5 15 26.07.23 19:48 Сейчас в теме

кто подскажет, где купить? можно б/у. просто 1с перестала выпускать. электронную версию не предлагать, она есть. нужен печатная версия

71. Дмитрий74Чел 250 25.12.25 17:33 Сейчас в теме

(70) Авито

Для отправки сообщения требуется регистрация/авторизация

Автор:

Игорь Кузнецов (Lucifer93)

Рейтинг: 100

Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.

Публикация:

№ 1078667

Создание 17.06.19 23:52

Обновление 17.06.19 23:52

Статистика:

Просмотры 27279

Загрузки 0

Рейтинг 95

Комментарии 73

Характеристики:

Код открыт Да

Рубрики Запросы

Кому Разработчик

Тип файла Нет файла

Платформа 1С:Предприятие 8

Конфигурация 1C:Бухгалтерия

Операционная система Не имеет значения

Страна Не имеет значения

Отрасль Не имеет значения

Налоги Не имеет значения

Вид учета Не имеет значения

Доступ к файлу Бесплатно (free)

Правила запроса. Выдержки из книги "Настольная книга 1С:Эксперта по технологическим вопросам"

См. также

Журнал

База знаний

Лаборатория

Анализ & Управление

Сопровождение 1С

Корпоративные решения

Обучение

Маркетплейс

Проектный офис

Мероприятия

Видеозаписи

Биржа заказов

Форум

Мерч

О компании