Срез на даты за период. Шаблон запроса
Введение
Довольно часто возникает задача в запросе получить актуальное значение ресурса на каждую дату выбранного периода.
Вот несколько таких случаев:
- Курс валюты на дату каждого документа за выбранный период
- Цену товара на дату реализации по всем реализациям за период
- Должность сотрудника на каждую дату периода
Традиционный подход
Наиболее интуитивный и часто применяемый способ следующий:
/// первый запрос - выбирает все даты документов
ВЫБРАТЬ РАЗЛИЧНЫЕ
НАЧАЛОПЕРИОДА(Товары.Ссылка.Дата, ДЕНЬ) КАК ДатаДокумента
ПОМЕСТИТЬ
ВТ_ДатыДокументов
ИЗ
Документ.Реализация.Товары КАК Товары
ГДЕ
Товары.Ссылка.Дата МЕЖДУ &НачалоПериода И &КонецПериода
;
/// второй запрос - выбирает из нашего регистра сведений измерения и максимальный период на каждую дату
ВЫБРАТЬ
ВТ_ДатыДокументов.ДатаДокумента,
Цены.Номенклатура,
МАКСИМУМ(Цены.Период) КАК ДатаЦены
ПОМЕСТИТЬ
ВТ_ДатыНачалаДействия
ИЗ
ВТ_ДатыДокументов КАК ВТ_ДатыДокументов
ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК Цены
ПО Цены.Период <= ВТ_ДатыДокументов.ДатаДокумента
ГДЕ
Цены.ТипЦены = &ТипЦены // например, такой отбор, или какой-нибудь другой
СГРУППИРОВАТЬ ПО
ВТ_ДатыДокументов.ДатаДокумента,
Цены.Номенклатура
;
/// третий запрос - выбирает из нашего регистра актуальные значения ресурсов на каждую дату документа
ВЫБРАТЬ
ВТ_ДатыНачалаДействия.ДатаДокумента,
Цены.Номенклатура,
Цены.Цена
ПОМЕСТИТЬ
ВТ_ЗначенияРесурсов
ИЗ
РегистрСведений.ЦеныНоменклатуры КАК Цены
ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ_ДатыНачалаДействия КАК ВТ_ДатыНачалаДействия
ПО ВТ_ДатыНачалаДействия.Период = Цены.Период
И ВТ_ДатыНачалаДействия.Номенклатура = Цены.Номенклатура
ГДЕ
Цены.ТипЦены = &ТипЦены // не забываем еще раз указать тот же отбор
;
/// четвертый запрос - основной, который получает нужные данные из временной таблицы, полученной на предыдущем шаге
ВЫБРАТЬ
Товары.Ссылка КАК Документ,
Товары.Номенклатура,
ВТ_ЗначенияРесурсов.Цена * Товары.Количество КАК Сумма // тут делаем что-то нужное нам с полученными значениями
ИЗ
Документ.Реализация.Товары КАК Товары
ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ_ЗначенияРесурсов КАК ВТ_ЗначенияРесурсов
ПО Товары.Номенклатура = ВТ_ЗначенияРесурсов.Номенклатура
И НАЧАЛОПЕРИОДА(Товары.Ссылка.Дата, ДЕНЬ) = ВТ_ЗначенияРесурсов.ДатаДокумента
Более продвинутые программисты могут объединить третий и четвертый шаг, что сократит количество временных таблиц. Но в примере оставим четыре шага ради большей наглядности
Также данный запрос может отличаться от автора к автору. Кто-то поймет, что это просто пример и уловит суть, но кто-то бросится в комментариях поправлять, оптимизировать и описывать свой опыт написания подобных запросов.
Но последовательность шагов обычно такая, как в этом типовом примере.
Я и сам по началу долгое время использовал именно такую схему.
Но данная схема неудобна по следующим причинам:
- Таблица, из которой мы выбираем даты документов - используется дважды. Если у нас не примитивный случай, а документы нужно брать, скажем, нескольких видов (через конструкцию ОБЪЕДИНИТЬ ВСЕ). То наш запрос вырастает в двух местах
- Но основное неудобство в том, что между основной таблицей (в нашем случае тч Товары) и регистром сведений (в нашем случае Цены номенклатуры) возникает связность в двух местах. То есть сначала мы должны будем написать самый последний запрос, чтобы понять какие даты нам нужны (в рабочем запросе это может оказаться не так просто сделать, как в приведенном примере). Потом повторить эту логику в первом запросе.
Когда пишешь сложный запрос, в котором срез на даты делается по нескольким регистрам (например, цены, валюты), в котором есть еще куча отборов и внутренних соединений, а также объединений, то данную схему использовать крайне неудобно.
Приведу пример. Когда-то в одной из конфигураций заказчика был непериодический регистр связи складов и подразделений. На этот регистр было завязано огромное количество отчетов. И вот однажды заказчик захотел сделать этот регистр связей складов и подразделений периодическим. Пройтись по всем отчетам, написанных разными разработчиками в разные годы и разобраться, как собрать таблицу дат в каждом из случаев - это была очень неприятная и трудоемкая работа. Плюс, конечно, запросы с этим регистром были не только в отчетах.
Подход со слабой связностью
Уже несколько лет для решения подобных задач, я использую другой подход - интервальный.
/// первый запрос - вытаскиваем из регистра сведений все что нужно за один раз
ВЫБРАТЬ
Период,
Номенклатура,
Цена
ПОМЕСТИТЬ ВТ_Срез
ИЗ
РегистрСведений.ЦеныНоменклатуры КАК Движения
ГДЕ
Период > &НачалоПериода
И Период <= &КонецПериода
И ТипЦены = &ТипЦены // например, такой отбор, или какой-нибудь другой
ОБЪЕДИНИТЬ ВСЕ
ВЫБРАТЬ
Период,
Номенклатура,
Цена
ИЗ
РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&НачалоПериода, ТипЦены = &ТипЦены // тут надо повторить отбор
) КАК Срез
ИНДЕКСИРОВАТЬ ПО
Движения.Номенклатура,
Движения.Период
;
/// второй запрос - собираем таблицу с периодами действия ресурса
ВЫБРАТЬ
НачалоПериода.Номенклатура,
НачалоПериода.Цена,
НачалоПериода.Период КАК НачалоПериода,
ЕСТЬNULL(ДОБАВИТЬКДАТЕ(МИНИМУМ(КонецПериода.Период), СЕКУНДА, -1), &КонецПериода) КАК КонецПериода
ПОМЕСТИТЬ ВТ_ЗначенияРесурсов
ИЗ
ВТ_Срез КАК НачалоПериода
ЛЕВОЕ СОЕДИНЕНИЕ ВТ_Срез КАК КонецПериода
ПО НачалоПериода.Номенклатура = КонецПериода.Номенклатура
И НачалоПериода.Период < КонецПериода.Период
СГРУППИРОВАТЬ ПО
НачалоПериода.Период,
НачалоПериода.Номенклатура,
НачалоПериода.Цена
;
/// третий запрос - основной, который получает нужные данные из временной таблицы, полученной на предыдущем шаге
ВЫБРАТЬ
Товары.Ссылка КАК Документ,
Товары.Номенклатура,
ВТ_ЗначенияРесурсов.Цена * Товары.Количество КАК Сумма // тут делаем что-то нужное нам с полученными значениями
ИЗ
Документ.Реализация.Товары КАК Товары
ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ_ЗначенияРесурсов КАК ВТ_ЗначенияРесурсов
ПО Товары.Номенклатура = ВТ_ЗначенияРесурсов.Номенклатура
И Товары.Ссылка.Дата МЕЖДУ ВТ_ЗначенияРесурсов.НачалоПериода И ВТ_ЗначенияРесурсов.КонецПериода
Плюсы интервального способа:
- Первые два шага довольно простые и не связаны с бизнес логикой основного запроса.
- Можно использовать данный запрос как шаблон, что значительно экономит время при разработке.
В итоге вся бизнес логика у нас перенеслась на последний запрос (то есть собралась в одно место). Это большой плюс при модификациях основного запроса.
Ну и конечно, в зависимости от задачи можно накладывать дополнительные отборы в первом шаге, чтобы оптимизировать работу запроса.
Заключение
Само собой у обоих способов могут быть ограничения в применении в каждом конкретном случае в зависимости от задачи. Но в моей практике я почти не использую первый способ, т.к. в подавляющем большинстве случаев применим второй способ.
Я выложил данный шаблон запроса главным образом для себя, т.к. довольно часто он пригождается. Но будет неплохо, если кто-нибудь сочтет его подходящим для себя.
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Инструментарий разработчика Роли и права Запросы СКД Разработчик Руководитель проекта 1С:Предприятие 8 Платные (руб)
Инструменты для разработчиков 1С 8.3 и 8.5: Infostart Toolkit. Автоматизация и ускорение разработки на управляемых формах. Легкость работы с 1С.
16500 руб.
02.09.2020 285573 1606 423
Инструментарий разработчика Запросы Разработчик 1С 8.3 1С:Бухгалтерия 3.0 1С:Зарплата и Управление Персоналом 3.x Абонемент ($m)
Структура запроса. Обработка визуально показывает, из какого количества подзапросов состоит запрос.
2 стартмани
06.07.2026 4945 65 XSlava 20
Запросы Разработчик 1С 8.3 Россия Бесплатно (free)
Визуальный «Конструктор запроса» 1С, встроенный прямо в VS Code, — аналог конструктора из Конфигуратора и EDT, но без запуска платформы. Расширение читает конфигурацию, выгруженную в файлы, позволяет собрать запрос мышью и генерирует корректный текст на языке запросов 1С (SDBL). Открывает уже существующий текст запроса из кода для правки и — что особенно ценно — сохраняет комментарии при цикле «открыть - править - сохранить». Подходит тем, кто пишет код 1С в VS Code, держит под рукой множество проектов и не хочет ради одного запроса запускать тяжёлый Конфигуратор или EDT.
26.06.2026 10660 Alex_YAM 7
Нейросети Инструментарий разработчика Запросы Разработчик 1С:Предприятие 8 Абонемент ($m)
Консоль запросов 1.0: добавлен ИИ-помощник (запрос в DeepSeek), который помогает быстрее получать каркас Запроса 1С Сформулируйте простое описание; нажмите кнопку – получите результат прямо в консоли. Где дальше его можно дорабатывать и тестировать. 28.5.2026 Добавил "Консоль запросов 2.0" (запрос в DeepSeek + Claude) 4.10.2026 Обновил "Консоль запросов 2.0"
3 стартмани
20.05.2026 9562 46 German4739 72
WEB-интеграция Запросы Разработчик 1С 8.3 Абонемент ($m)
Post1C - это внешняя обработка, которая превращает 1С в полноценный инструмент для тестирования REST API. Всё управление сосредоточено в одном окне: настройка запроса, выполнение, просмотр ответа и генерация кода - без переключения между формами. Аналог Postman, но работающий в привычной среде 1С.
1 стартмани
02.04.2026 4638 105 priem_nv 27
Запросы Механизмы типовых конфигураций Разработчик 1С:Предприятие 8 1С:Управление торговлей 11 Россия Бесплатно (free)
Предлагается обзор работы с объектной моделью запроса по схемам запросов типовым функционалом УТ 11.5.
09.10.2025 13397 aximo 18
Инструментарий разработчика Запросы Разработчик 1С:Предприятие 8 1С:Зарплата и кадры государственного учреждения 3 1С:Зарплата и Управление Персоналом 3.x Абонемент ($m)
QueryConsole1C — расширение, включающее консоль запросов с поддержкой исполняемых представлений — аналогов виртуальных таблиц, основанных на методах программного интерфейса ЗУП. Оно позволяет выполнять запросы с учётом встроенной бизнес-логики, отлаживать алгоритмы получения данных и автоматически генерировать код на встроенном языке 1С.
1 стартмани
16.05.2025 13660 168 zup_dev 32
Инструментарий разработчика Запросы Разработчик 1С:Предприятие 8 1С:ERP Управление предприятием 2 Абонемент ($m)
В данной публикации рассказывается о решении, которое позволяет находить сразу все ошибки в тексте запроса за раз, а не только самую первую.
2 стартмани
05.03.2025 7714 25 XilDen 12
И Период <= &КонецПериодаа чуть далее
ЕСТЬNULL(ДОБАВИТЬКДАТЕ(МИНИМУМ(КонецПериода.Период), СЕКУНДА, -1), ДАТАВРЕМЯ(3000, 1, 1))почему ДАТАВРЕМЯ(3000, 1, 1) , а не &КонецПериода ?
//эмуляция РС.Цены
Выбрать ДатаВремя(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
типа
выбрать
ТаблицаОбъекта.Ссылка,
Т1.Период,
Т1.Срез1,
....
Т1.СрезХ,
Т1.Ресурс /// искомое значение
ИЗ ТАблицаОбъекта
ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ПериодичностьЧегоТо КАК Т1
ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ПериодичностьЧегоТо КАК Т2
ПО Т1.Срез1 = Т2.Срез1 И....И Т1.СрезХ = Т2.СрезХ
ПО ТаблицаОбъекта.Дата >= Т1.Период И ТаблицаОбъектов.Ссылка В (&Ссылки)
СГРУППИРОВАТЬ ПО
ТаблицаОбъекта.Ссылка,
Т1.Период,
Т1.Срез1,
....
Т1.СрезХ,
Т1.Ресурс /// искомое значение!!!
ИМЕЮЩИЕ Т1.Период = Масимум(Т2.Период)
З.Ы. Мог где-то ошибиться, это общий вид запроса. думаю смысл его понятен.
Гораздо выгоднее с точки зрения производительности накладывать группировку только на таблицу с периодичностью, чем группировать запрос с кучей соединений.
А с точки зрения удобства работы с основным запросом, не выгодно делать соединения, задваивающие в нем записи без необходимости
Тета-соединение - довольно затратная операция, и накладывать его обычно лучше отдельно
1. Для разовых операций это не критично, если жесткач, то можно установить порции
2. Для неразовых также можно устанавливать порции. В реальных задачах пользователю что нужно обрабатывать полностью всю таблицу объектов? Он же п.3
3. в 99% случаев есть отбор с х-количеством документов/ссылок и т.д. объем которых редко превышает 40 (динамический список например) или ТЧ документа ну несколько тыс строк
З.Ы. Нада ориентироваться конкретной задачей, нельзя пытаться натянуть любой метод решения на глобус, нет ничего универсального. Например списание партий в запросе - там тоже происходит мерж джоин со своей временной сложностью
Можно, конечно, продолжать накидывать аргументы в защиту каждого, но пользы от этого я не вижу.
Вывод такой: оба варианта можно использовать. Каждый выбирает тот, который удобнее и применим в конкретной задаче
Привожу свои:
1. Не согласен, что вариант с двумя левыми соединениями и группировкой более читаемый. Считаю, что в моем варианте первые два запроса - служебные и не требуют чтения и погружения. Зато основной запрос становится более читаемым, гибким и быстрым.
2. У меня как то была задача, чтобы в отчёте пересчитать сумму из валюты документа в валюту, выбранную пользователем. Так вот, моим вариантом эта задача решилась просто, нужно было лишь дважды присоединить таблицу с интервалами. С твоим способом пришлось бы цеплять тета-соединение дважды.
3. Но мой способ не подойдёт для динамического списка, например.
Правильный вывод: знаем все подходы, применяем - наиболее подходящий в каждой конкретной задаче
Для динамического списка есть еще такая фишка как коррелируемый запрос, когда делается соединение с нужной таблицей в подзапросе типа 1 В (выбрать 1 из НужнойТаблицы где Поле1 = ВнешнийЗапрос.Поле1) и получаем сразу нужный срез. Т.е. можно написать тоже самое, что делает EXIST в tsql. Кстати на скуль это так и переносится, если глянуть профайлер. Идеально для получения всяких статусов и прочего непосредственно в запросе ДС, а не при при получении данных. Если ты полностью фиксируешь измерения, то там index seek и работает это шустро. Не раз применял такое при оптимизации всяких костылей.
Гипотетически - не гипотетически, а такие варианты возможны, и их надо предусматривать. Поэтому хотелось бы увидеть ваш вариант. Мой -- очень громоздкий получается.
ВЫБРАТЬ
Продажи.Период,
Продажи.Контрагент,
Продажи.Номенклатура,
Продажи.КоличествоОборот КАК Количество,
Продажи.СтоимостьОборот КАК Стоимость,
ЦеныНоменклатуры.Цена
ИЗ
РегистрНакопления.Продажи.Обороты(&НачалоПериода, &КонецПериода, День, ) КАК Продажи
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦеныНоменклатуры
ПО Продажи.Номенклатура = ЦеныНоменклатуры.Номенклатура
И (ЦеныНоменклатуры.ТипЦен = &ТипЦен)
И (ЦеныНоменклатуры.Период В
(ВЫБРАТЬ ПЕРВЫЕ 1
Цены.Период
ИЗ
РегистрСведений.ЦеныНоменклатуры КАК Цены
ГДЕ
Цены.Период <= Продажи.Период
И Цены.Номенклатура = Продажи.Номенклатура
И Цены.ТипЦен = &ТипЦен
УПОРЯДОЧИТЬ ПО
Цены.Период УБЫВ)) ПоказатьВЫБРАТЬ
РеализацияТоваровУслуг.Ссылка КАК Ссылка,
РеализацияТоваровУслуг.Дата КАК Дата,
КурсыВалют.Курс КАК Курс
ИЗ
Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг
ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
КурсыВалют.Период КАК Период,
КурсыВалют.Курс КАК Курс
ИЗ
РегистрСведений.КурсыВалют КАК КурсыВалют
ГДЕ
КурсыВалют.Период МЕЖДУ НАЧАЛОПЕРИОДА(&дата1, ДЕНЬ) И КОНЕЦПЕРИОДА(&дата2, ДЕНЬ)
И КурсыВалют.Валюта = &Валюта) КАК КурсыВалют
ПО (НАЧАЛОПЕРИОДА(РеализацияТоваровУслуг.Дата, ДЕНЬ) = КурсыВалют.Период)
ГДЕ
РеализацияТоваровУслуг.Дата МЕЖДУ НАЧАЛОПЕРИОДА(&дата1, ДЕНЬ) И КОНЕЦПЕРИОДА(&дата2, ДЕНЬ) ПоказатьВ случае цен конечно такой вариант не прокатит =)
И так к сведению, есть валюты, для которых курс изменяется не каждый день. Самый банальный пример такой валюты - это рубль, у которого курс = 1 и задан один раз. Но есть и другие более экзотические валюты
"ВЫБРАТЬ
| Движения.Период КАК Период,
| Движения.Номенклатура КАК Номенклатура,
| Движения.Цена КАК Цена
|ПОМЕСТИТЬ ВТ_Срез
|ИЗ
| РегистрСведений.ЦеныНоменклатуры КАК Движения
|ГДЕ
| Движения.Период > &НачалоПериода
| И Движения.Период <= &КонецПериода
| И Движения.ВидЦены = &ВидЦены
| И Движения.Номенклатура = &Номенклатура
|
|ОБЪЕДИНИТЬ ВСЕ
|
|ВЫБРАТЬ
| Срез.Период,
| Срез.Номенклатура,
| Срез.Цена
|ИЗ
| РегистрСведений.ЦеныНоменклатуры.СрезПоследних(
| &НачалоПериода,
| ВидЦены = &ВидЦены
| И Номенклатура = &Номенклатура) КАК Срез
|
|ИНДЕКСИРОВАТЬ ПО
| Движения.Номенклатура,
| Движения.Период
|;
|
|//////////////////////////////////////////////////////////// ////////////////////
|ВЫБРАТЬ
| НачалоПериода.Номенклатура КАК Номенклатура,
| НачалоПериода.Цена КАК Цена,
| НачалоПериода.Период КАК НачалоПериода,
| ЕСТЬNULL(ДОБАВИТЬКДАТЕ(МИНИМУМ(КонецПериода.Период), СЕКУНДА, -1), &КонецПериода) КАК КонецПериода
|ПОМЕСТИТЬ ВТ_ЗначенияРесурсов
|ИЗ
| ВТ_Срез КАК НачалоПериода
| ЛЕВОЕ СОЕДИНЕНИЕ ВТ_Срез КАК КонецПериода
| ПО НачалоПериода.Номенклатура = КонецПериода.Номенклатура
| И НачалоПериода.Период < КонецПериода.Период
|
|СГРУППИРОВАТЬ ПО
| НачалоПериода.Период,
| НачалоПериода.Номенклатура,
| НачалоПериода.Цена
|;
|
|//////////////////////////////////////////////////////////// ////////////////////
|ВЫБРАТЬ
| Товары.Ссылка КАК Документ,
| Товары.Номенклатура КАК Номенклатура,
| ВТ_ЗначенияРесурсов.Цена * Товары.Количество КАК Сумма,
| ВТ_ЗначенияРесурсов.Цена КАК Цена,
| ВТ_ЗначенияРесурсов.НачалоПериода КАК НачалоПериода,
| ВТ_ЗначенияРесурсов.КонецПериода КАК КонецПериода
|ИЗ
| Документ.РеализацияТоваровУслуг.Товары КАК Товары
| ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ_ЗначенияРесурсов КАК ВТ_ЗначенияРесурсов
| ПО Товары.Номенклатура = ВТ_ЗначенияРесурсов.Номенклатура
| И (Товары.Ссылка.Дата МЕЖДУ ВТ_ЗначенияРесурсов.НачалоПериода И ВТ_ЗначенияРесурсов.КонецПериода)
|ГДЕ
| Товары.Ссылка.Дата МЕЖДУ &НачалоПериода И &КонецПериода"
ПоказатьНо все это перестает работать, когда в регистре цен овер 100 млн строк...
И тогда на сцену выходит тот самый Ваш первый вариант (где 3й и 4й пакет сделаны 1м пакетом).
Потому как на таких объемах данных уже играет роль способность сервера БД в целом переварить такую выборку, а также дисковая подсистема и особенно tempdb
Но ты заявляешь, насколько я понимаю, что для любой задачи с любыми данными какой-то один способ лучше. Это подозрительно.
Я очень сильно сомневаюсь, что ты проверял каждый из перечисленных здесь способов.
Все что у тебя есть это твои предположения, которые ты не подтвердил цифрами.
Если бы ты хотя бы привел пример, то можно было бы уже предметно подискутировать. Тогда я бы с тобой согласился бы или нет.
Но мне не известно что ты там и на каких данных проверял.
Хотя бы привел пример, что за такой периодический регистр сведений со 100 млн. записей ? Что вы в нем такого храните? И что за задачи ты там решал где "проверял на как раз таких данных, и не раз"?
На практике бывает так, что когда у тебя есть трудности с производительностью, то пробуешь все более менее подходящие способы. И очень часто самым лучшим оказывается не тот, на который ты думал вначале.
Так что благодарю за ценные замечания. Твоя информация оказалась весьма полезной и содержательной.
Насчет ты-вы. Я считаю нормальным, когда коллеги общаются на ты, это обычно упрощает коммуникацию. Когда ко мне обращаются на ты, для меня это норма и я в ответ тоже перехожу на ты. Очень редки случаи, когда кто-то говорит шаблонную фразу, что "мы с тобой что-то не делали". Обычно это говорит о том, что человек не настроен на конструктивное общение. Но это уже не моя проблема.
Насчет хамства. Давай-ка процетируй какие именно слова из моих комментариев ты посчитал хамством.
Насчет твоих выводов.
В комментарии 29 ты упомянул три способа, а в комментарии 33 ты пишешь, что сравнивал только два из них. То есть как я и написал в комментарии 32, ты не проверял ВСЕ способы. Но при этом ты уже сделал вывод о производительности.
Почитай комментарий 8, где я как раз и писал, что вариант с двумя соединениями к периодическому регистру (который ты называешь тета-соединение), является менее производительным. Что собственно и совпадает с приведенными тобой примерами.
Но каких-то оснований для того, чтобы сделать вывод о производительности варианта с интервалами, я в твоих комментариях не увидел, хотя ты сделал такой вывод в комментарии 29. Поэтому я изначально постарался избежать бесполезной дискуссии в комментарии 30.
Насчет приводимых тобой примеров и доказательств.
К сожалению, твои комментарии содержат очень мало конкретных убедительных аргументов.
Аргументы типа "Я все это проверял", "изначально хотел сделать скриншоты" и т.д. в таком духе - это не аргументы.
Насчет 100 млн. записей.
Я видел регистры накопления и с миллиардом записей. Но регистр цен на 100 млн. записей - трудно представить. По моей оценке это 10 лет нужно устанавливать цены на 5000 позиций по 5 видам цен ЕЖЕДНЕВНО.
Я себе с трудом могу представить отрасль, в которой было бы 5000 АКТИВНЫХ позиций номенклатуры на которую ЕЖЕДНЕВНО меняют цены.
Собственно это и выглядит неправдоподобно.
А судя по твоему комментарию 29, в варианте с интервалами вроде как нужно выгружать эти 100 млн. записей во временную таблицу. Или тогда я не понимаю, почему этот аргумент приводится к этому способу в комментарии 29.
Насчет неадекватной реакции
Цитирую: "с учётом Вашей неадекватной реакции на вполне спокойный комментарий".
Не понял в чем проявилась неадекватность? Всего навсего задал вопросы для уточнения и не более того.
Тут на ИС очень много разработчиков, которые считают себя спецами. Но когда начинаешь задавать конкретные вопросы, то объяснить не могут.
Я понимаю, что ты не тролль и отношусь к тебе с уважением. Но если ты хочешь покритиковать (в данном случае ты покритиковал производительность приведенного в статье метода), то будь добр приведи убедительные аргументы и технические подробности, иначе может возникнуть недопонимание
Я добавил регистр сведений зависимый по регистратору к документу РеализацияТовароуУслуг. При проведении реализации сохраняю цены на товар: цены закупа, цены продажи (с учетом скидки менеджера), прайсовая цена, ответственный.
Отчетом по данному регистру очччень быстро получаю динамику цен, сверку по каждому менеджеру, отклонения от прайсовой цены.
Решать задачу получения цен через запрос сложнее и в моем случае нецелесообразно было...
1. Не подошел в твоем конкретном случае (ты так считаешь)
2. Решать задачу получения цен через запрос сложнее (дело квалификации, а не целесообразности)
Ты при проведении реализации пишешь в регистр цены закупа (а также все остальные цены) и считаешь это нормальным.
Только один этот факт говорит о многом.
Твоя аргументация против данного способа слабовата, попробуй подобрать более объективные аргументы.
Я не поддержал применимость сложного запроса только к одной задаче. Я не против применения запроса для расчета среза дат за период, но я сталкивался с тем, что отчет, формирующийся за длительный период - например за три года, просто вылетает в ошибку "не хватает памяти".
Задача с реализациями не такая тривиальная как кажется: особенно когда имеются динамически рассчитываемые цены, которые не хранятся в базе, на лету считаются в определенный момент события.
В моем случае задача стояла такая - вот менеджеры работают, продают, делают скидки клиентам. Как посмотреть цена за товар в момент реализации какой категории соответствовала? Условно есть 6 категорий динамических цен в прайсе (со своими скидками).
Я придумал простое решение, создал регистр, прописал проведение реализации, перепровел все реализации за период - достаточно быстро - вывел регистр в отчет на СКД. За час руководитель видел статистику по менеджерам.
Не вижу проблем с моим подходом.
Возможно мы решали разные задачи, возможно у вас задача без запроса никак не решалась....
На первом скриншоте регистр и алгоритм проведения движений.
На втором скриншоте типовой механизм УТ - расчета динамических цен при проверке допустимости цен для менеджеров.
В принципе не хотел вас задеть. Так что мир, труд, май!
И сначала проверяй свой код, прежде чем выкладывать, чтобы не опозориться
1. НайтиПоКоду() - для тебя это норма?
2. Запросы в цикле
3. Запросы пишешь как стажер :
левое соединение (выбрать ... из Регистр.ЦеныНоменклатуры) как ВложенныйЗапрос = просто левое соединение из Регистр.ЦеныНоменклатуры
зачем усложнять код без необходимости вложенными запросами. Также применение подзапросов не позволяет СУБД использовать индексы (если знаешь что это такое)
4. динамическая сборка запроса (конкатенация) не позволяет проверить его конструктором запроса на валидность. Чтобы уйти от формирования текста запроса динамически - используй конструкцию "ВЫБОР КОГДА" в твоем случае она бы подошла
5. Ты пишешь в регистр данные, которые можно вычислить на лету. Из-за этого база растет чуть быстрее. Если ты используешь такие подходы регулярно, то база начинает увеличиваться уже заметно быстрее. Но это конечно уже не твоя проблема.
Вот чтобы не использовать запросы в цикле и были описаны методы в статье, а также в комментариях к ней.
И да, чтобы это применить нужно подтянуть технику написания запросов. С твоим уровнем квалификации описанные в статье методы применить сложновато.
1. для меня норма, и для многих других
2. запрос в цикле - именно шулай, ты можешь это не использовать,
3. типовой механизм не я прописывал, а разработчики 1с - тысячи пользователей работают в УТ 10.3, и ничего - проблем не знают... а когда сталкиваются, решают без пены у рта, как некоторые....
4. за ростом базы следят, это первый регистр, который чистят раз в квартал, на больший период данные не интересны...
5. вычисляй на лету - если нравится, но свой способ не навязывай.
ну значит, не договорились, все заканчиваю спор - отчаливаю
НАЧАЛОПЕРИОДА(Товары.Ссылка.Дата, ДЕНЬ) КАК ДатаДокумента
Для чего здесь НАЧАЛОПЕРИОДА ?
А если цена менялась внутри дня, и было две продажи - одна ДО изменения цены, другая после, то с конструкцией
НАЧАЛОПЕРИОДА будет выведена одинаковая цена для двух этих продаж ?
Или не будет ?
Рейтинг: 3437
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 1118145
Создание 05.09.19 09:30
Обновление 05.09.19 09:30
Просмотры 39662
Загрузки 0
Рейтинг
117
Комментарии 44
Код открыт Да
Рубрики Запросы
Кому Разработчик
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация 1C:Бухгалтерия
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)