Оптимальное соединение с виртуальной таблицей регистра сведений
Для расчета стоимости проданного товара в ценах закупа на текущую дату
было использовано левое соединение с виртуальной таблицей
РегистрСведений.ЦеныНоменклатуры.СрезПоследних()
Избегая *,
вынес получение цен в отдельный набор данных, сделав соединение.
Как замерить эффект изменений и стоило менять основной запрос с учетом того, что в вычисляемых полях уменьшилась читаемость кода в полях Наценка и Маржинальность из-за вынужденной замены операнда ВыручкаВЦенахЗакупа на Количество*ЦенаЗакупа?
было использовано левое соединение с виртуальной таблицей
РегистрСведений.ЦеныНоменклатуры.СрезПоследних()
Избегая *,
вынес получение цен в отдельный набор данных, сделав соединение.
Как замерить эффект изменений и стоило менять основной запрос с учетом того, что в вычисляемых полях уменьшилась читаемость кода в полях Наценка и Маржинальность из-за вынужденной замены операнда ВыручкаВЦенахЗакупа на Количество*ЦенаЗакупа?
* При обращении к этим виртуальным таблицам платформа автоматически извлекает из регистров накопления нужные данные, группирует их по измерениям и выдает пользователю некоторую обобщенную информацию – итоговые значения ресурсов регистров в разрезе измерений. Для этого используются итоговые таблицы регистров, к которым невозможно обратиться с помощью языка запросов.
Если в запросе выбираются данные из виртуальных таблиц, то при трансляции запроса в язык SQL платформа сама обращается к итоговым таблицам регистров. В случаях, когда часть информации получается из таблицы итогов, а часть – из таблицы движений регистра, соединение с виртуальной таблицей на уровне SQL может быть реализовано как соединение с подзапросом. В этом случае оптимизатор СУБД может точно так же выбрать неоптимальный план, как при работе с подзапросом в явном виде (см. предыдущий раздел).
Если в запросе выбираются данные из виртуальных таблиц, то при трансляции запроса в язык SQL платформа сама обращается к итоговым таблицам регистров. В случаях, когда часть информации получается из таблицы итогов, а часть – из таблицы движений регистра, соединение с виртуальной таблицей на уровне SQL может быть реализовано как соединение с подзапросом. В этом случае оптимизатор СУБД может точно так же выбрать неоптимальный план, как при работе с подзапросом в явном виде (см. предыдущий раздел).
Прикрепленные файлы:
По теме из базы знаний
- Регистры накопления. Виртуальные таблицы. Часть №2: "Остатки" и "Остатки и обороты"
- Регистры сведений. За кулисами
- Как сдать экзамен 1С:Специалист по платформе?
- Регистры бухгалтерии. Виртуальная таблица оборотов
- Быстрый фронт в базе размером 6.8 терабайт – наши стандарты при разработке и рефакторинге запросов
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(3) Согласен. Однажды я оптимизировал тяжёлый запрос по рекомендациям 1с. Увы - выполняться он стал дольше. Оптимизировал и другие, но они не такие тяжёлые - не мерил скорость.
(1) Эффект можно измерить "в лоб". 2 идентичные процедуры, отличаются только запросом "старый" и "новый" (собственно выполнение запроса только и нужно). В цикле по очереди выполняются обе процедуры (первая, вторая, первая, вторая, ...). с суммированием времени в разрезе каждой процедуры на одних и тех же больших объемах данных. Раз 10-20. У кого время лучше - тот и победил.
(1) Эффект можно измерить "в лоб". 2 идентичные процедуры, отличаются только запросом "старый" и "новый" (собственно выполнение запроса только и нужно). В цикле по очереди выполняются обе процедуры (первая, вторая, первая, вторая, ...). с суммированием времени в разрезе каждой процедуры на одних и тех же больших объемах данных. Раз 10-20. У кого время лучше - тот и победил.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот