Срез на даты за период. Шаблон запроса

05.09.19

Разработка - Запросы

Один запрос, который довольно часто пригождался.

Введение

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

Вот несколько таких случаев:

  • Курс валюты на дату каждого документа за выбранный период
  • Цену товара на дату реализации по всем реализациям за период
  • Должность сотрудника на каждую дату периода

 

Традиционный подход


Наиболее интуитивный и часто применяемый способ следующий:

/// первый запрос - выбирает все даты документов

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

/// второй запрос - выбирает из нашего регистра сведений измерения и максимальный период на каждую дату
ВЫБРАТЬ
	ВТ_ДатыДокументов.ДатаДокумента,
	Цены.Номенклатура,
	МАКСИМУМ(Цены.Период) КАК ДатаЦены
ПОМЕСТИТЬ 
	ВТ_ДатыНачалаДействия
ИЗ 
	ВТ_ДатыДокументов КАК ВТ_ДатыДокументов
	ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК Цены
    	ПО Цены.Период <= ВТ_ДатыДокументов.ДатаДокумента
	
ГДЕ
	Цены.ТипЦены = &ТипЦены // например, такой отбор, или какой-нибудь другой

СГРУППИРОВАТЬ ПО
	ВТ_ДатыДокументов.ДатаДокумента,
	Цены.Номенклатура
;

/// третий запрос - выбирает из нашего регистра актуальные значения ресурсов на каждую дату документа
ВЫБРАТЬ
	ВТ_ДатыНачалаДействия.ДатаДокумента,
	Цены.Номенклатура,
	Цены.Цена
	
ПОМЕСТИТЬ 
	ВТ_ЗначенияРесурсов
ИЗ 
	РегистрСведений.ЦеныНоменклатуры КАК Цены
	ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ_ДатыНачалаДействия КАК ВТ_ДатыНачалаДействия
    	ПО ВТ_ДатыНачалаДействия.Период = Цены.Период
    	И ВТ_ДатыНачалаДействия.Номенклатура = Цены.Номенклатура
ГДЕ
	Цены.ТипЦены = &ТипЦены // не забываем еще раз указать тот же отбор
;

/// четвертый запрос - основной, который получает нужные данные из временной таблицы, полученной на предыдущем шаге
ВЫБРАТЬ
	Товары.Ссылка КАК Документ,
	Товары.Номенклатура,
	ВТ_ЗначенияРесурсов.Цена * Товары.Количество КАК Сумма // тут делаем что-то нужное нам с полученными значениями
ИЗ 
	Документ.Реализация.Товары КАК Товары
	ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ_ЗначенияРесурсов КАК ВТ_ЗначенияРесурсов
    	ПО Товары.Номенклатура = ВТ_ЗначенияРесурсов.Номенклатура
    	И НАЧАЛОПЕРИОДА(Товары.Ссылка.Дата, ДЕНЬ) = ВТ_ЗначенияРесурсов.ДатаДокумента


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

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

Но последовательность шагов обычно такая, как в этом типовом примере.

Я и сам по началу долгое время использовал именно такую схему.

Но данная схема неудобна по следующим причинам:

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

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

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

 

Подход со слабой связностью 

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

/// первый запрос - вытаскиваем из регистра сведений все что нужно за один раз
ВЫБРАТЬ
    Период,
    Номенклатура,
    Цена
ПОМЕСТИТЬ ВТ_Срез
ИЗ 
    РегистрСведений.ЦеныНоменклатуры КАК Движения
ГДЕ 
    Период > &НачалоПериода
    И Период <= &КонецПериода
    И ТипЦены = &ТипЦены // например, такой отбор, или какой-нибудь другой

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

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

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

СГРУППИРОВАТЬ ПО
    НачалоПериода.Период,
    НачалоПериода.Номенклатура,
    НачалоПериода.Цена
;

/// третий запрос - основной, который получает нужные данные из временной таблицы, полученной на предыдущем шаге
ВЫБРАТЬ
	Товары.Ссылка КАК Документ,
	Товары.Номенклатура,
	ВТ_ЗначенияРесурсов.Цена * Товары.Количество КАК Сумма // тут делаем что-то нужное нам с полученными значениями
ИЗ 
	Документ.Реализация.Товары КАК Товары
	ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ_ЗначенияРесурсов КАК ВТ_ЗначенияРесурсов
    	ПО Товары.Номенклатура = ВТ_ЗначенияРесурсов.Номенклатура
    	И Товары.Ссылка.Дата МЕЖДУ ВТ_ЗначенияРесурсов.НачалоПериода И ВТ_ЗначенияРесурсов.КонецПериода

Плюсы интервального способа:

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

В итоге вся бизнес логика у нас перенеслась на последний запрос (то есть собралась в одно место). Это большой плюс при модификациях основного запроса.

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

 

Заключение

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

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

См. также

Инструментарий разработчика Роли и права Запросы СКД Программист Платформа 1С v8.3 Управляемые формы Запросы Система компоновки данных Конфигурации 1cv8 Платные (руб)

Набор инструментов программиста и специалиста 1С для всех конфигураций на управляемых формах. В состав входят инструменты: Консоль запросов, Консоль СКД, Консоль кода, Редактор объекта, Анализ прав доступа, Метаданные, Поиск ссылок, Сравнение объектов, Все функции, Подписки на события и др. Редактор запросов и кода с раскраской и контекстной подсказкой. Доработанный конструктор запросов тонкого клиента. Продукт хорошо оптимизирован и обладает самым широким функционалом среди всех инструментов, представленных на рынке.

10000 руб.

02.09.2020    151389    833    397    

841

Запросы Программист Запросы Бесплатно (free)

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

16.08.2024    6737    user1840182    5    

27

Математика и алгоритмы Запросы Программист Платформа 1С v8.3 Запросы Бесплатно (free)

Рассмотрим быстрый алгоритм поиска дублей с использованием hash функции по набору полей шапки и табличных частей.

08.07.2024    2062    ivanov660    9    

22

Запросы СКД Программист Стажер Система компоновки данных Россия Бесплатно (free)

Часто при разработке отчетов в СКД возникает ситуация, когда не совсем понятно, почему отчет выводит не те данные, которые нужны, либо не выводит вовсе. Возникает потребность увидеть конечный запрос, который формирует СКД. Как это сделать, рассмотрим в этой статье.

15.05.2024    7106    implecs_team    6    

46

Запросы Программист Стажер Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Часто поступают задачи по произвольному распределению общих сумм. После распределения иногда пропадают копейки. Суть решения добавить АвтоНомерЗаписи() в ВТ распределения, и далее используя функции МАКСИМУМ или МИНИМУМ можем положить разницу копеек в первую или последнюю строку знаменателя распределения.

11.04.2024    3186    andrey_sag    10    

35

Запросы СКД Программист Стажер Платформа 1С v8.3 Запросы Система компоновки данных 1С:ERP Управление предприятием 2 Бесплатно (free)

В типовых конфигурациях разработчики компании 1С иногда используют в отчетах, построенных на СКД, такую конструкцию, как "ГДЕ ЛОЖЬ". Такая конструкция говорит о том, что данные в запросе не будут получены совсем. Для чего же нужен тогда запрос?

13.02.2024    7291    KawaNoNeko    23    

26

Запросы СКД Программист Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Абонемент ($m)

Есть список полей в виде текста, или запрос - закидываем в набор СКД.

1 стартмани

31.01.2024    2954    3    Yashazz    0    

34
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. alex-l19041 8 05.09.19 10:20 Сейчас в теме
любопытно... в самом первом запросе

 И Период <= &КонецПериода


а чуть далее

ЕСТЬNULL(ДОБАВИТЬКДАТЕ(МИНИМУМ(КонецПериода.Период), СЕКУНДА, -1), ДАТАВРЕМЯ(3000, 1, 1))


почему ДАТАВРЕМЯ(3000, 1, 1) , а не &КонецПериода ?
4. json 3346 05.09.19 10:32 Сейчас в теме
(1) согласен, это неточность.
Вечером подправлю
2. soft_wind 05.09.19 10:23 Сейчас в теме
давно уже подобную задачу решают одним запросом (без всяких временных таблиц) с двумя левыми соединениями
collider; TerveRus; +2 Ответить
5. json 3346 05.09.19 10:35 Сейчас в теме
(2) ты давай-ка приведи пример.
А то может ты что-нибудь путаешь или не учитываешь.
10. soft_wind 05.09.19 11:25 Сейчас в теме
(5) вот простенький пример, легко масштабируется на более сложные условия
//эмуляция РС.Цены
Выбрать ДатаВремя(2019,1,1) как Период, "Тов1" как Номенклатура, 110 как Цена Поместить РегЦены
Объединить все Выбрать ДатаВремя(2019,1,5), "Тов1", 150 
Объединить все Выбрать ДатаВремя(2019,1,9), "Тов1", 190 
Объединить все Выбрать ДатаВремя(2019,1,1), "Тов2", 210 
Объединить все Выбрать ДатаВремя(2019,1,9), "Тов2", 290 
;

//эмуляция документа
Выбрать ДатаВремя(2019,1,6) как Дата, "Тов1" как Номенклатура Поместить Док
Объединить все Выбрать ДатаВремя(2019,1,6), "Тов2"
Объединить все Выбрать ДатаВремя(2019,1,6), "Тов3"
;

выбрать 
	Док.*,
	ЕстьNull(Рег1.Цена,0) как Цена, 
	Рег1.Период //для анализа
из 
	Док

левое соединение РегЦены Рег1	
	по Док.Номенклатура = Рег1.Номенклатура 
	и Док.Дата >= Рег1.Период 

левое соединение РегЦены Рег2	
	по Док.Номенклатура = Рег2.Номенклатура 
	и Док.Дата >= Рег2.Период 
	и Рег2.Период > Рег1.Период 
где
	Рег2.Период есть Null	

Показать


получаем такой результат
Дата Номенклатура Цена Период
06.01.2019 0:00:00 Тов1 150 05.01.2019 0:00:00
06.01.2019 0:00:00 Тов2 210 01.01.2019 0:00:00
06.01.2019 0:00:00 Тов3 0

по Тов1 цена взялась от 05,01,2019
а по Тов2 от 01,01,2019
OzzY; collider; BigB; adva; asupsam; json; +6 Ответить
12. json 3346 05.09.19 11:37 Сейчас в теме
(10) уже обсудили этот вариант в комментариях чуть ранее.

Больше ничего не добавлю.

Но приятно, что есть разработчики, которые готовы поддержать свои комментарии кодом, а не просто ради того чтобы покритиковать да сумничать
3. catena 110 05.09.19 10:28 Сейчас в теме
Подобные задачи гуглятся по запросу "срез последних на каждую дату". Хорошо бы автору добавить подобное упоминание, иначе способ бесславно утонет.
baracuda; erutan; +2 Ответить
6. json 3346 05.09.19 10:36 Сейчас в теме
(3) спасибо. Добавлю в текст
7. cool99 05.09.19 10:41 Сейчас в теме
Не вникал в смысл задачи, но срез на дату чего-либо по периоду делается простым 1 запросом без всяких ВТ.
типа
выбрать
ТаблицаОбъекта.Ссылка,
Т1.Период,
Т1.Срез1,
....
Т1.СрезХ,
Т1.Ресурс /// искомое значение
ИЗ ТАблицаОбъекта
ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ПериодичностьЧегоТо КАК Т1
ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ПериодичностьЧегоТо КАК Т2
ПО Т1.Срез1 = Т2.Срез1 И....И Т1.СрезХ = Т2.СрезХ
ПО ТаблицаОбъекта.Дата >= Т1.Период И ТаблицаОбъектов.Ссылка В (&Ссылки)
СГРУППИРОВАТЬ ПО
ТаблицаОбъекта.Ссылка,
Т1.Период,
Т1.Срез1,
....
Т1.СрезХ,
Т1.Ресурс /// искомое значение!!!

ИМЕЮЩИЕ Т1.Период = Масимум(Т2.Период)

З.Ы. Мог где-то ошибиться, это общий вид запроса. думаю смысл его понятен.
8. json 3346 05.09.19 10:51 Сейчас в теме
(7) ну вот ты и задвоил записи в основном запросе. Теперь представь, что в основной таблице очень много записей, которых теперь может стать на один- два порядка больше ( если формировать, скажем, за месяц). И возможно, что в основном запросе ещё куча показателей, требующих соединения с другими таблицами, при расчете которых ты теперь уже не можешь использовать функцию СУММА ()

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

Тета-соединение - довольно затратная операция, и накладывать его обычно лучше отдельно
9. cool99 05.09.19 11:20 Сейчас в теме
(8)
1. Для разовых операций это не критично, если жесткач, то можно установить порции
2. Для неразовых также можно устанавливать порции. В реальных задачах пользователю что нужно обрабатывать полностью всю таблицу объектов? Он же п.3
3. в 99% случаев есть отбор с х-количеством документов/ссылок и т.д. объем которых редко превышает 40 (динамический список например) или ТЧ документа ну несколько тыс строк

З.Ы. Нада ориентироваться конкретной задачей, нельзя пытаться натянуть любой метод решения на глобус, нет ничего универсального. Например списание партий в запросе - там тоже происходит мерж джоин со своей временной сложностью
11. json 3346 05.09.19 11:30 Сейчас в теме
(9) мы с тобой рассмотрели два подхода к решению одной задачи в общем случае.

Можно, конечно, продолжать накидывать аргументы в защиту каждого, но пользы от этого я не вижу.

Вывод такой: оба варианта можно использовать. Каждый выбирает тот, который удобнее и применим в конкретной задаче
15. cool99 05.09.19 13:40 Сейчас в теме
(11) Ну имхо 1 запрос более читаем, все сделали в одном месте и сразу. Кроме того, есть преимущество в том, что не нужно создавать индексы во ВТ, а используются физические индексы самих таблиц и как раз то при большом количестве записей будет выигрыш. Вообще всегда нужно использовать именно их
16. json 3346 05.09.19 14:11 Сейчас в теме
(15) услышал твои аргументы.
Привожу свои:
1. Не согласен, что вариант с двумя левыми соединениями и группировкой более читаемый. Считаю, что в моем варианте первые два запроса - служебные и не требуют чтения и погружения. Зато основной запрос становится более читаемым, гибким и быстрым.
2. У меня как то была задача, чтобы в отчёте пересчитать сумму из валюты документа в валюту, выбранную пользователем. Так вот, моим вариантом эта задача решилась просто, нужно было лишь дважды присоединить таблицу с интервалами. С твоим способом пришлось бы цеплять тета-соединение дважды.
3. Но мой способ не подойдёт для динамического списка, например.

Правильный вывод: знаем все подходы, применяем - наиболее подходящий в каждой конкретной задаче
17. cool99 05.09.19 15:56 Сейчас в теме
(16) Ну по поводу читаемости, как на скуле пишу, так флиент юзаю в ентити фреймворк (которые многие терпеть не могут, предпочитая декларативный тип), что руками и в консоли в 1С - не вижу особой разницы в читаемости нескольких соединений. Тут спорить смысла нет, так как на вкус и цвет фломастеры разные :)

Для динамического списка есть еще такая фишка как коррелируемый запрос, когда делается соединение с нужной таблицей в подзапросе типа 1 В (выбрать 1 из НужнойТаблицы где Поле1 = ВнешнийЗапрос.Поле1) и получаем сразу нужный срез. Т.е. можно написать тоже самое, что делает EXIST в tsql. Кстати на скуль это так и переносится, если глянуть профайлер. Идеально для получения всяких статусов и прочего непосредственно в запросе ДС, а не при при получении данных. Если ты полностью фиксируешь измерения, то там index seek и работает это шустро. Не раз применял такое при оптимизации всяких костылей.
13. premierex 204 05.09.19 13:26 Сейчас в теме
(0)
НАЧАЛОПЕРИОДА(Товары.Ссылка.Дата, ДАТА)

Не знал, что у функции НАЧАЛОПЕРИОДА() есть такой параметр "ДАТА". У меня запрос сразу выдаёт ошибку: Неверные параметры ... <<?>>ДАТА...
14. json 3346 05.09.19 13:34 Сейчас в теме
(13) опечатка. Вечером поправлю. Правильно ДЕНЬ, а не ДАТА
18. Pim 185 05.09.19 21:16 Сейчас в теме
А как учитывает ваш запрос периодичность по позиции регистратора? Правильно он отработает, если любимый пользователь введёт два документа с одинаковой датой?
19. json 3346 05.09.19 21:39 Сейчас в теме
(18) чисто гипотетически если такая необходимость будет, то можно доработать запрос.
Но пока не могу придумать пример, где бы такое могло потребоваться в реальной задаче.
20. Pim 185 05.09.19 22:10 Сейчас в теме
(19). Уважаемый, я вам только подготовил картинки по вашему комментарию, а вы его изменили. ;-)
Гипотетически - не гипотетически, а такие варианты возможны, и их надо предусматривать. Поэтому хотелось бы увидеть ваш вариант. Мой -- очень громоздкий получается.
21. json 3346 05.09.19 22:14 Сейчас в теме
(20) да я изменил свой комментарий, потому что понял, что был не прав ))
Попробую набросать и выложить, посмотрим, что получится (и получится ли)
22. zqzq 25 06.09.19 08:46 Сейчас в теме
Есть ещё вариант с помощью коррелирующего подзапроса (производительность нужно проверять, но запрос достаточно красивый):

ВЫБРАТЬ
    Продажи.Период,
    Продажи.Контрагент,
    Продажи.Номенклатура,
    Продажи.КоличествоОборот КАК Количество,
    Продажи.СтоимостьОборот КАК Стоимость,
    ЦеныНоменклатуры.Цена
ИЗ
    РегистрНакопления.Продажи.Обороты(&НачалоПериода, &КонецПериода, День, ) КАК Продажи
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦеныНоменклатуры
        ПО Продажи.Номенклатура = ЦеныНоменклатуры.Номенклатура
            И (ЦеныНоменклатуры.ТипЦен = &ТипЦен)
            И (ЦеныНоменклатуры.Период В
                (ВЫБРАТЬ ПЕРВЫЕ 1
                    Цены.Период
                ИЗ
                    РегистрСведений.ЦеныНоменклатуры КАК Цены
                ГДЕ
                    Цены.Период <= Продажи.Период
                    И Цены.Номенклатура = Продажи.Номенклатура
                    И Цены.ТипЦен = &ТипЦен
                УПОРЯДОЧИТЬ ПО
                    Цены.Период УБЫВ))
Показать
baracuda; TerveRus; stas1976; json; shard; triviumfan; +6 Ответить
23. triviumfan 96 06.09.19 11:21 Сейчас в теме
(22) Я такой использую в отчете "выручка и с/с продаж", производительность устраивает.
24. ip0593 20 06.09.19 11:26 Сейчас в теме
меня зарубили на одном собеседовании за то, что я на бумажке не смог написать данный запрос, а попросил сесть за комп.
25. triviumfan 96 06.09.19 12:07 Сейчас в теме
(24) обычно там требуют не срез на каждую дату, а срез на дату :)
26. ip0593 20 06.09.19 13:20 Сейчас в теме
(25)у меня требовали срез на каждую дату)
27. shard 281 06.09.19 16:07 Сейчас в теме
а почему не рассматривается вариант для курсов валют
ВЫБРАТЬ
	РеализацияТоваровУслуг.Ссылка КАК Ссылка,
	РеализацияТоваровУслуг.Дата КАК Дата,
	КурсыВалют.Курс КАК Курс
ИЗ
	Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг
		ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
			КурсыВалют.Период КАК Период,
			КурсыВалют.Курс КАК Курс
		ИЗ
			РегистрСведений.КурсыВалют КАК КурсыВалют
		ГДЕ
			КурсыВалют.Период МЕЖДУ НАЧАЛОПЕРИОДА(&дата1, ДЕНЬ) И КОНЕЦПЕРИОДА(&дата2, ДЕНЬ)
			И КурсыВалют.Валюта = &Валюта) КАК КурсыВалют
		ПО (НАЧАЛОПЕРИОДА(РеализацияТоваровУслуг.Дата, ДЕНЬ) = КурсыВалют.Период)
ГДЕ
	РеализацияТоваровУслуг.Дата МЕЖДУ НАЧАЛОПЕРИОДА(&дата1, ДЕНЬ) И КОНЕЦПЕРИОДА(&дата2, ДЕНЬ)
Показать

В случае цен конечно такой вариант не прокатит =)
28. json 3346 06.09.19 16:16 Сейчас в теме
(27) потому что в теме фигурирует "срез последних". В твоем запросе нет среза.

И так к сведению, есть валюты, для которых курс изменяется не каждый день. Самый банальный пример такой валюты - это рубль, у которого курс = 1 и задан один раз. Но есть и другие более экзотические валюты
42. serko8547 111 29.06.22 10:47 Сейчас в теме
Добавлю от себя, вывод цен по дням. Может кому пригодится. (код писался для УТ 11)


"ВЫБРАТЬ
|	Движения.Период КАК Период,
|	Движения.Номенклатура КАК Номенклатура,
|	Движения.Цена КАК Цена
|ПОМЕСТИТЬ ВТ_Срез
|ИЗ
|	РегистрСведений.ЦеныНоменклатуры КАК Движения
|ГДЕ
|	Движения.Период > &НачалоПериода
|	И Движения.Период <= &КонецПериода
|	И Движения.ВидЦены = &ВидЦены
|	И Движения.Номенклатура = &Номенклатура
|
|ОБЪЕДИНИТЬ ВСЕ
|
|ВЫБРАТЬ
|	Срез.Период,
|	Срез.Номенклатура,
|	Срез.Цена
|ИЗ
|	РегистрСведений.ЦеныНоменклатуры.СрезПоследних(
|			&НачалоПериода,
|			ВидЦены = &ВидЦены
|				И Номенклатура = &Номенклатура) КАК Срез
|
|ИНДЕКСИРОВАТЬ ПО
|	Движения.Номенклатура,
|	Движения.Период
|;
|
|////////////////////////////////////////////////////////////­////////////////////
|ВЫБРАТЬ
|	НачалоПериода.Номенклатура КАК Номенклатура,
|	НачалоПериода.Цена КАК Цена,
|	НачалоПериода.Период КАК НачалоПериода,
|	ЕСТЬNULL(ДОБАВИТЬКДАТЕ(МИНИМУМ(КонецПериода.Период), СЕКУНДА, -1), &КонецПериода) КАК КонецПериода
|ПОМЕСТИТЬ ВТ_ЗначенияРесурсов
|ИЗ
|	ВТ_Срез КАК НачалоПериода
|		ЛЕВОЕ СОЕДИНЕНИЕ ВТ_Срез КАК КонецПериода
|		ПО НачалоПериода.Номенклатура = КонецПериода.Номенклатура
|			И НачалоПериода.Период < КонецПериода.Период
|
|СГРУППИРОВАТЬ ПО
|	НачалоПериода.Период,
|	НачалоПериода.Номенклатура,
|	НачалоПериода.Цена
|;
|
|////////////////////////////////////////////////////////////­////////////////////
|ВЫБРАТЬ
|	Товары.Ссылка КАК Документ,
|	Товары.Номенклатура КАК Номенклатура,
|	ВТ_ЗначенияРесурсов.Цена * Товары.Количество КАК Сумма,
|	ВТ_ЗначенияРесурсов.Цена КАК Цена,
|	ВТ_ЗначенияРесурсов.НачалоПериода КАК НачалоПериода,
|	ВТ_ЗначенияРесурсов.КонецПериода КАК КонецПериода
|ИЗ
|	Документ.РеализацияТоваровУслуг.Товары КАК Товары
|		ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ_ЗначенияРесурсов КАК ВТ_ЗначенияРесурсов
|		ПО Товары.Номенклатура = ВТ_ЗначенияРесурсов.Номенклатура
|			И (Товары.Ссылка.Дата МЕЖДУ ВТ_ЗначенияРесурсов.НачалоПериода И ВТ_ЗначенияРесурсов.КонецПериода)
|ГДЕ
|	Товары.Ссылка.Дата МЕЖДУ &НачалоПериода И &КонецПериода"


Показать
29. Dach 380 06.09.19 17:32 Сейчас в теме
Слабая связанность, тета-соединение - прекрасные варианты.

Но все это перестает работать, когда в регистре цен овер 100 млн строк...

И тогда на сцену выходит тот самый Ваш первый вариант (где 3й и 4й пакет сделаны 1м пакетом).

Потому как на таких объемах данных уже играет роль способность сервера БД в целом переварить такую выборку, а также дисковая подсистема и особенно tempdb
30. json 3346 06.09.19 18:01 Сейчас в теме
(29) не буду переубеждать
31. Dach 380 06.09.19 22:21 Сейчас в теме
(30) так и не надо. Я все это проверял на как раз таких данных, и не раз
32. json 3346 06.09.19 23:20 Сейчас в теме
(31) если бы ты был известным экспертом в области производительности, то я бы тебе конечно поверил.
Но ты заявляешь, насколько я понимаю, что для любой задачи с любыми данными какой-то один способ лучше. Это подозрительно.

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

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

Но мне не известно что ты там и на каких данных проверял.
Хотя бы привел пример, что за такой периодический регистр сведений со 100 млн. записей ? Что вы в нем такого храните? И что за задачи ты там решал где "проверял на как раз таких данных, и не раз"?

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

Так что благодарю за ценные замечания. Твоя информация оказалась весьма полезной и содержательной.
33. Dach 380 07.09.19 11:50 Сейчас в теме
(32) во-первых, не ты, а Вы. Мы с Вами водку на брудершафт не пили. Элементарная вежливость, нет? Во-вторых, если Вы бд видели таблиц со 100 млн записей, это не значит, что их нет. Продажи, множество типов цен, множество позиций товара, цены меняются каждый день, вот и ответ. И да, я проверял работу тета-соединения для получения среза цен на каждую дату. И первый запрос (первый подход, точнее) выиграл у него по скорости в 2.5 раза. И я всего лишь поделился реальным опытом. Доказывать что-то лично Вам желания нет (с учётом Вашей неадекватной реакции на вполне спокойный комментарий). Хотя изначально хотел сделать скриншоты из консоли. Общение общением, хамить то зачем?
34. json 3346 08.09.19 09:28 Сейчас в теме
(33)
Насчет ты-вы. Я считаю нормальным, когда коллеги общаются на ты, это обычно упрощает коммуникацию. Когда ко мне обращаются на ты, для меня это норма и я в ответ тоже перехожу на ты. Очень редки случаи, когда кто-то говорит шаблонную фразу, что "мы с тобой что-то не делали". Обычно это говорит о том, что человек не настроен на конструктивное общение. Но это уже не моя проблема.

Насчет хамства. Давай-ка процетируй какие именно слова из моих комментариев ты посчитал хамством.

Насчет твоих выводов.
В комментарии 29 ты упомянул три способа, а в комментарии 33 ты пишешь, что сравнивал только два из них. То есть как я и написал в комментарии 32, ты не проверял ВСЕ способы. Но при этом ты уже сделал вывод о производительности.
Почитай комментарий 8, где я как раз и писал, что вариант с двумя соединениями к периодическому регистру (который ты называешь тета-соединение), является менее производительным. Что собственно и совпадает с приведенными тобой примерами.
Но каких-то оснований для того, чтобы сделать вывод о производительности варианта с интервалами, я в твоих комментариях не увидел, хотя ты сделал такой вывод в комментарии 29. Поэтому я изначально постарался избежать бесполезной дискуссии в комментарии 30.

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

Насчет 100 млн. записей.
Я видел регистры накопления и с миллиардом записей. Но регистр цен на 100 млн. записей - трудно представить. По моей оценке это 10 лет нужно устанавливать цены на 5000 позиций по 5 видам цен ЕЖЕДНЕВНО.
Я себе с трудом могу представить отрасль, в которой было бы 5000 АКТИВНЫХ позиций номенклатуры на которую ЕЖЕДНЕВНО меняют цены.
Собственно это и выглядит неправдоподобно.
А судя по твоему комментарию 29, в варианте с интервалами вроде как нужно выгружать эти 100 млн. записей во временную таблицу. Или тогда я не понимаю, почему этот аргумент приводится к этому способу в комментарии 29.

Насчет неадекватной реакции
Цитирую: "с учётом Вашей неадекватной реакции на вполне спокойный комментарий".
Не понял в чем проявилась неадекватность? Всего навсего задал вопросы для уточнения и не более того.
Тут на ИС очень много разработчиков, которые считают себя спецами. Но когда начинаешь задавать конкретные вопросы, то объяснить не могут.
Я понимаю, что ты не тролль и отношусь к тебе с уважением. Но если ты хочешь покритиковать (в данном случае ты покритиковал производительность приведенного в статье метода), то будь добр приведи убедительные аргументы и технические подробности, иначе может возникнуть недопонимание
35. Dach 380 08.09.19 13:19 Сейчас в теме
(34) 10 тыс позиций, 100 и более типов цен. По сути, для каждого клиента делается свой тип цен. Это спорно с точки зрения архитектуры решения, но мне лично досталось вот в таком виде, приходится жить с этим. 3 измерения в регистре: товар, тип, спецусловия. Цены меняются каждый день! Ежедневный прирост строк в таблице рс - 1 млн! Цены ставят как руками, так и из файлов загружают. А в некоторых региональных базах и более. Запросы к ценам у нас - самое узкое место в системе. И есть ряд хитрых архитектурных решений, призванных облегчить эти запросы (в 2 словах не описать, тянет не отдельную публикацию). В том числе каждые несколько месяцев средствами бд формируется срез последних (содержит 1.5-2 млн уникальных строк), движения этого среза крепятся к регистратору с пустой тч. Все цены до регистратора - удаляются. Если этого не делать - таблица регистра просто становится неперевариваемой. Мы пробовали разные способы - и отдельные итоги для среза последних и да, тета-соединение в запросе. Будет полчаса лишних на работе - покажу Вам замеры. Кроме того, при интерактивном подборе товаров в заказы, менеджеры всегда хотят видеть актуальные цены, для этого есть механизм кэширования по ключам аналитики, где каждый ключ - Товар+НаборАналитик+ТипЦены. Так что, коллега, ситуации бывают всякие. Слабую связанность ещё не проверял толком, но так как там есть большая выборка плюс срез, потом их джойн - думаю, что проиграет первому подходу. А первый подход хорош тем, что попадает в кластерный индекс регистра.
36. RustIG 1727 02.06.20 10:24 Сейчас в теме
(0) описанный способ решения задачи
Цену товара на дату реализации по всем реализациям за период
не поддерживаю.
Я добавил регистр сведений зависимый по регистратору к документу РеализацияТовароуУслуг. При проведении реализации сохраняю цены на товар: цены закупа, цены продажи (с учетом скидки менеджера), прайсовая цена, ответственный.
Отчетом по данному регистру очччень быстро получаю динамику цен, сверку по каждому менеджеру, отклонения от прайсовой цены.

Решать задачу получения цен через запрос сложнее и в моем случае нецелесообразно было...
37. json 3346 02.06.20 14:18 Сейчас в теме
(36) Насколько я понял, ты не поддерживаешь по двум причинам:

1. Не подошел в твоем конкретном случае (ты так считаешь)
2. Решать задачу получения цен через запрос сложнее (дело квалификации, а не целесообразности)

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

Твоя аргументация против данного способа слабовата, попробуй подобрать более объективные аргументы.
38. RustIG 1727 02.06.20 15:54 Сейчас в теме
"Срез на даты за период" - задача одна из сложных, часто встречающаяся. То, что вы предложили некоторый анализ и свое видение - плюс вам в карму. Я не вникал в суть ваших изысканий - поскольку придется "читать запросы с пониманием" - пока мне не нужно тратить на это время.

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

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

В моем случае задача стояла такая - вот менеджеры работают, продают, делают скидки клиентам. Как посмотреть цена за товар в момент реализации какой категории соответствовала? Условно есть 6 категорий динамических цен в прайсе (со своими скидками).

Я придумал простое решение, создал регистр, прописал проведение реализации, перепровел все реализации за период - достаточно быстро - вывел регистр в отчет на СКД. За час руководитель видел статистику по менеджерам.

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

На первом скриншоте регистр и алгоритм проведения движений.
На втором скриншоте типовой механизм УТ - расчета динамических цен при проверке допустимости цен для менеджеров.

В принципе не хотел вас задеть. Так что мир, труд, май!
Прикрепленные файлы:
39. json 3346 06.06.20 13:06 Сейчас в теме
(38) если отвечаешь на пост, то используй кнопку "Ответить" (она находится слева внизу сообщения, на которое ты отвечаешь).

И сначала проверяй свой код, прежде чем выкладывать, чтобы не опозориться

1. НайтиПоКоду() - для тебя это норма?
2. Запросы в цикле
3. Запросы пишешь как стажер :
левое соединение (выбрать ... из Регистр.ЦеныНоменклатуры) как ВложенныйЗапрос = просто левое соединение из Регистр.ЦеныНоменклатуры
зачем усложнять код без необходимости вложенными запросами. Также применение подзапросов не позволяет СУБД использовать индексы (если знаешь что это такое)
4. динамическая сборка запроса (конкатенация) не позволяет проверить его конструктором запроса на валидность. Чтобы уйти от формирования текста запроса динамически - используй конструкцию "ВЫБОР КОГДА" в твоем случае она бы подошла
5. Ты пишешь в регистр данные, которые можно вычислить на лету. Из-за этого база растет чуть быстрее. Если ты используешь такие подходы регулярно, то база начинает увеличиваться уже заметно быстрее. Но это конечно уже не твоя проблема.

Вот чтобы не использовать запросы в цикле и были описаны методы в статье, а также в комментариях к ней.
И да, чтобы это применить нужно подтянуть технику написания запросов. С твоим уровнем квалификации описанные в статье методы применить сложновато.
40. RustIG 1727 06.06.20 15:33 Сейчас в теме
(39)
1. для меня норма, и для многих других
2. запрос в цикле - именно шулай, ты можешь это не использовать,
3. типовой механизм не я прописывал, а разработчики 1с - тысячи пользователей работают в УТ 10.3, и ничего - проблем не знают... а когда сталкиваются, решают без пены у рта, как некоторые....
4. за ростом базы следят, это первый регистр, который чистят раз в квартал, на больший период данные не интересны...
5. вычисляй на лету - если нравится, но свой способ не навязывай.
ну значит, не договорились, все заканчиваю спор - отчаливаю
41. independ 1543 22.06.22 12:15 Сейчас в теме
Отличное решение с интервалами, потребовалось выгружать срезы розничных цен товаров, по которым есть движения в группировке по дням из регистра ТоварыНаСкладах почти за годовой период. Получилось очень быстро. Респект.
43. simuljakr 203 07.12.23 22:30 Сейчас в теме
Подскажите пожалуйста, а зачем в первом запросе используется

НАЧАЛОПЕРИОДА(Товары.Ссылка.Дата, ДЕНЬ) КАК ДатаДокумента

Для чего здесь НАЧАЛОПЕРИОДА ?

А если цена менялась внутри дня, и было две продажи - одна ДО изменения цены, другая после, то с конструкцией
НАЧАЛОПЕРИОДА будет выведена одинаковая цена для двух этих продаж ?
Или не будет ?
Оставьте свое сообщение