Запускайте два варианта запроса, сравнивайте результаты.

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

Запрос 1:

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


Запрос 2: (внезапно быстрее в 2 раза)

ВЫБРАТЬ
    ЦТекущие.Номенклатура.Ссылка КАК Ссылка,
    ЦТекущие.Период КАК ПериодТекущий,
    ЕСТЬNULL(ЦТекущие.Цена, 0) КАК ЦенаТекущая,
    ЦПрошлые.Период КАК ПериодПрошлый,
    ЕСТЬNULL(ЦПрошлые.Цена, 0) КАК ЦенаПрошлая
ИЗ
    Справочник.Номенклатура КАК ТН
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры.СрезПоследних(, ВидЦены = &ВидЦены) КАК ЦТекущие
        ПО (ЦТекущие.Номенклатура = ТН.Ссылка)
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦПрошлые
        ПО (ЦПрошлые.ВидЦены = &ВидЦены)
            И (ЦПрошлые.Номенклатура = ТН.Ссылка)
            И (ЦПрошлые.Период < ЦТекущие.Период)
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦВсе
        ПО (ЦВсе.ВидЦены = &ВидЦены)
            И (ЦВсе.Номенклатура = ТН.Ссылка)
            И (ЦВсе.Период > ЦПрошлые.Период)
            И (ЦВсе.Период < ЦТекущие.Период)
ГДЕ
    ЦВсе.Цена ЕСТЬ NULL
    И НЕ ЦТекущие.Цена ЕСТЬ NULL
    И НЕ ЦПрошлые.Цена ЕСТЬ NULL


хотя не, потестил на болших объемах. Первый 468 секунд, вилка 556 (3723 позиции номенклатуры)

(0) А если предпоследней цены нету, то запросы неправильные. Оба.

ВТ, где ВТ...

Гений ..... не проще без всякой дрочи твоей один запрс по регистру сведений без среза. но модно поставить дату начала и дату конца (между)
Делаешь группировкой период и выводишь отчет - колонками даты (без времени в запросе).

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

У меня отчеты по ценам на 10 000 позиций - 1 секунда.
На 100 000 - 7-10 секунд.

У тебя какая то дрочь кривая на 3 000 позиций - 460 секунд... рука лицо.

Хоч можно даже календарь прилепить. получить недельные даты. и вывести отчет за последние две недели. как менялись цены понедельно. какая мин-макс-средняя цена была...

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

(13) запрос в студию, проверю скорость

(15) см. пункт (12) все же понятно

(16) понятно, что там неправильно.

(17) так и в твоём запросе дичь

(15) кому все это надо, если срезпоследних стопицот лет назад изобрели и встроили в систему. Время бы пожалели...

Напоминаю правило форума №2: "Флейм и оффтопик в тематических разделах 1С и IT не допускается."

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

(19) здесь срез последних не прокатит. Для каждой номенклатуры нужен срез на свою дату.

(3) нет, ты ошибаешься. тут как раз сравнение последней и предпоследней цен. Если предпоследней цены нет, то этот товар не попадет в отчет, там отбор по NULL сработает. И это правильно.

А если так

ВЫБРАТЬ
    ТН.Ссылка КАК Ссылка,
    Ц.Период КАК Период,
    Ц.Цена КАК Цена
ИЗ
    Справочник.Номенклатура КАК ТН
    ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК Ц
    ПО (Ц.ВидЦены = &ВидЦены)
        И (Ц.Номенклатура = ТН.Ссылка)
        И (Ц.Период В
(           ВЫБРАТЬ ПЕРВЫЕ 2
                Ц1.Период КАК Период
            ИЗ
                РегистрСведений.ЦеныНоменклатуры КАК Ц1
            ГДЕ
                Ц1.Номенклатура = ТН.Ссылка
                И Ц.1ВидЦены = &ВидЦены
            УПОРЯДОЧИТЬ ПО
                Период УБЫВ))


колонки делать при выводе

(22) "Если предпоследней цены нет, то этот товар не попадет в отчет" - соединение со справочником - излишнее. Я тебе сэкономил кучу времени, гы-гы :)

Хотя вот такие косяки нелепо делать
ЦТекущие.Номенклатура.Ссылка КАК Ссылка

Думал, что Гений "срез последних двух" навелосипедил.
Ан нет, не осилил еще.

(24) (23) задачу не ту решаешь. Нужно последнее изменение цены отловить. а не все
(25) ну типа того, да.

(28) если нужно только те что цена менялась, то сгруппировать и МИН(Цена) <> Макс(Цена)

(29) перечитай условие. Последняя и предпоследняя цена, короче, где произошло уменьшение цены, чтобы выставить поле "Старая цена" для сайта. При этом если давно поменялась цена, то сбросить это поле. Тольок свежие изменения

1.88 сек, строк 39243


ВЫБРАТЬ
    ТаблицаПериодов.Номенклатура КАК Номенклатура,
    ТаблицаПериодов.ПослПериод КАК ПослПериод,
    ПослЦеныНоменклатуры.Цена КАК ПослЦена,
    ТаблицаПериодов.ПредПериод КАК ПредПериод,
    ПредЦеныНоменклатуры.Цена КАК ПредЦена
ИЗ
    (ВЫБРАТЬ
        ЦеныНоменклатуры.Номенклатура КАК Номенклатура,
        МИНИМУМ(ЦеныНоменклатуры.Период) КАК ПредПериод,
        МАКСИМУМ(ЦеныНоменклатуры.Период) КАК ПослПериод
    ИЗ
        РегистрСведений.ЦеныНоменклатуры КАК ЦеныНоменклатуры
    ГДЕ
        ЦеныНоменклатуры.ВидЦены = &ВидЦены
        И ЦеныНоменклатуры.Период В
                (ВЫБРАТЬ ПЕРВЫЕ 2
                    ЦеныКрайние.Период
                ИЗ
                    РегистрСведений.ЦеныНоменклатуры КАК ЦеныКрайние
                ГДЕ
                    ЦеныКрайние.Номенклатура = ЦеныНоменклатуры.Номенклатура
                    И ЦеныКрайние.ВидЦены = &ВидЦены
                УПОРЯДОЧИТЬ ПО
                    ЦеныКрайние.Период УБЫВ)
    
    СГРУППИРОВАТЬ ПО
        ЦеныНоменклатуры.Номенклатура
    
    ИМЕЮЩИЕ
        МИНИМУМ(ЦеныНоменклатуры.Период) <> МАКСИМУМ(ЦеныНоменклатуры.Период)) КАК ТаблицаПериодов
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ПредЦеныНоменклатуры
        ПО (ТаблицаПериодов.Номенклатура = ПредЦеныНоменклатуры.Номенклатура)
            И (ПредЦеныНоменклатуры.ВидЦены = &ВидЦены)
            И (ПредЦеныНоменклатуры.Период = ТаблицаПериодов.ПредПериод)
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ПослЦеныНоменклатуры
        ПО (ТаблицаПериодов.Номенклатура = ПослЦеныНоменклатуры.Номенклатура)
            И (ПослЦеныНоменклатуры.ВидЦены = &ВидЦены)
            И (ПослЦеныНоменклатуры.Период = ТаблицаПериодов.ПослПериод)

(31) о, кстати, а это идея, использовать первые X в предложении В, не знал о таком.
но там кстати, может не прокатить. т.к цены могут идти так 10, 20, 20.
Получишь 20, 20, а надо 10, 20

(32) хотя там просто добавить проверку на неравенство цене и будет работать

(32) ты перед тем как писать - читай внимательно, там первые 2 ПЕРИОДа

(33) и проверка там есть

(34) ну вот тебе пример:
1 янв  10
2 янв  20
3 янв  20
4 янв  20

что у тебя выдаст?
надо
1 янв 10
4 янв 20

(31) кстати, а зачем внутри В упорядочить?

(36) направление задано, можно копать. прирост скорости на порядки

(38) да, надо поэкспериментировать

спасибо

Хорошо что пятница.

(37) догадайся

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

(43) зачем таблицу итогов класть во временную?

(44) Поверять нужно, может и нет смысла.

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

(36) с добавлениями:

ВЫБРАТЬ
    ТаблицаПериодов.Номенклатура КАК Номенклатура,
    ТаблицаПериодов.ПослПериод КАК ПослПериод,
    ПослЦеныНоменклатуры.Цена КАК ПослЦена,
    ТаблицаПериодов.ПредПериод КАК ПредПериод,
    ПредЦеныНоменклатуры.Цена КАК ПредЦена
ИЗ
    (ВЫБРАТЬ
        ЦеныНоменклатуры.Номенклатура КАК Номенклатура,
        МИНИМУМ(ЦеныНоменклатуры.Период) КАК ПредПериод,
        МАКСИМУМ(ЦеныНоменклатуры.Период) КАК ПослПериод
    ИЗ
        РегистрСведений.ЦеныНоменклатуры КАК ЦеныНоменклатуры
    ГДЕ
        ЦеныНоменклатуры.ВидЦены = &ВидЦены
        И ЦеныНоменклатуры.Период В
                (ВЫБРАТЬ ПЕРВЫЕ 2
                    МАКСИМУМ(ЦеныКрайние.Период) КАК Период
                ИЗ
                    РегистрСведений.ЦеныНоменклатуры КАК ЦеныКрайние
                ГДЕ
                    ЦеныКрайние.Номенклатура = ЦеныНоменклатуры.Номенклатура
                    И ЦеныКрайние.ВидЦены = &ВидЦены
                СГРУППИРОВАТЬ ПО
                    ЦеныКрайние.Цена
                УПОРЯДОЧИТЬ ПО
                    Период УБЫВ)
    
    СГРУППИРОВАТЬ ПО
        ЦеныНоменклатуры.Номенклатура
    
    ИМЕЮЩИЕ
        МИНИМУМ(ЦеныНоменклатуры.Период) <> МАКСИМУМ(ЦеныНоменклатуры.Период)) КАК ТаблицаПериодов
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ПредЦеныНоменклатуры
        ПО (ТаблицаПериодов.Номенклатура = ПредЦеныНоменклатуры.Номенклатура)
            И (ПредЦеныНоменклатуры.ВидЦены = &ВидЦены)
            И (ПредЦеныНоменклатуры.Период = ТаблицаПериодов.ПредПериод)
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ПослЦеныНоменклатуры
        ПО (ТаблицаПериодов.Номенклатура = ПослЦеныНоменклатуры.Номенклатура)
            И (ПослЦеныНоменклатуры.ВидЦены = &ВидЦены)
            И (ПослЦеныНоменклатуры.Период = ТаблицаПериодов.ПослПериод)

не знаю, считать ли это оффтопом, но в установке цен в УТ справа внизу есть команда "настроить=> показывать действующие цены". или тут тема про секундами померяться?

(48) необязательно это обрабатывается там

(48) это же печать ценников, а не установка цен

я правильно понимаю - ТС опозорился?

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

Ибо план запроса первого запроса и тысячного могут очень сильно отличаться

(46) че-то я затупил, можно было ЦТек и ЦПред. Вот тут почитал и подобрались эти идентификаторы идеально

(52) план запроса в файловой?

(54) ты пытаешься что-то оптимизировать для файловых баз?

брось это занятие, оно просто бессмысленно....

(55) +
я уверен, что в данном топике никому не пришло в голову, что ты ведешь речь о ФАЙЛОВЫХ базах.

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

(53) гениальней только ц1 и ц2

(56) (55) Почему бес-смысленной? Задача то реальная. Там не нужна особая скорость. Регл. задание отрабатиывает и ладно.

(59) как ты сразу съехал, что скорость не нужна
а накатал то https://geniy1s.ru/novyj-podhod-k-nestandartnomu-srezu-poslednih-vilka-fiksina/

(60) и где там про то, что скорость нужна? в каком абзаце?

Ну и вообще - это не вилка фиксина, а коррелированный подзапрос

(61) "Как видно, на больших объемах вилка работает несколько медленнее. Есть идеи как ускорить?" - если бы скорость была не нужно, то и этой строчки бы не было. Логично?

так вся тема как раз про то что новый БЫСТРЫЙ метод.
иначе зачем этот метод нужен

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

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

Сравни с текстом (31). Кстати, думаю, там быстро отработало из-за SQL, думаю на файловой этот запрос покажет удручающие результаты, он все еще считается, гггг

Ну если восстановить последовательность, то.
Сначала я написал запрос вилкой.
Потом переписал на классику. Зачем уже не помню.
Потом мне показалось что вилка быстрее (на демо-базе УТ она быстрее шуршала).
Но потом запустил на реальной, когда уже пост печатнул и увидел, что вилка медленнее.
Такая цепочка.

(67) свое всегда ближе к телу

так в (0) тоже не решает проблему одинаковых цен, а в (47) решает

(31) Вынужден констатировать НафНаф, что вы ввели нас в заблуждение. Ваш код умер на моей базе. Правда, это не прод, а копия прода у меня на компьютере. Но уже минут 20 висит, так что не жду чудес от производительности. протестируйте ка на своей базе два других варианта, а то сравнивать результаты на разных базах не имеет смысла. Ггг..

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

еще в (12) написал нормальное решение...

(71) так ты и есть мальчик, обслуживающий ларьки
тестируем только нормальные сервера на SQL

(72) у этого решения есть два существенных недостатка:
1. Нет кода запроса.
2. Это решение не моей задачи, а какой-то другой

Раз пошла такая пьянка....
Добавь в расширение регистр сведений Изменения цен и пиши в ресурсы две цены: Старая, Новая, а также Дату смены цены в разрезе измерений Номенклатура, Вид цены. И записывай при необходимости.
Гениально же?

(73) увы, но получается что запросы от многоуважаемого НафНаф это фуфел, потому что он не сравнивал их производительность со скоростью классики и вилки. Так что продолжаем дискуссию.

(75) а не слишком ли это жирно для банальной маркетинговой задачи? а? ггг

(74) геня ты шутишь?)

Ты не можешь вывести регистр сведений по датам?

(76) Тебе решать. Доступно и всерьёз ©1С

Бутылка Клейна, Ложка Фолькмана, Вилка Фиксина

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

У себя сделал регистр сведений ИсторияИзмененияЦен. И в момент проведения как раз делаю запрос по ценам доки и старым прошлым ценам. И ТОЛЬКО если есть отличие пишу в регистр иистории.

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

(76) так у тебя решение не полное, проблему одинаковых цен не решает

(0)
Глаз режет. Я бы так не стал. Но гению виднее.

(82)
На вскидку должно не так быстро работать как могло бы.

Ого, запрос от НафНаф ставит антирекорды скорости - 1999 секунд в сравнении с другими двумя это космос, конечно. Раза в 4 медленнее

(82) что тебе режет? Декартово произведение? имхо, нормальный ход, зато прозрачный в отличии от максимумов разных

(80) молодец. у себя - это где?

(85) в мегапрайсе)

(85)
Я так не делаю.
Где тут декартово произведение?

(81) нашел до чего докопаться, а есть так? ггг


ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦПрошлые
        ПО (ЦПрошлые.ВидЦены = &ВидЦены)
            И (ЦПрошлые.Номенклатура = ТН.Ссылка)
             И (ЦПрошлые.Период < ЦТекущие.Период)
            И (ЦПрошлые.Цена <> ЦТекущие.Цена)


А? А!

(85)
Мы видимо под декартовыми произведениями разные вещи понимаем )

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

(90) ты видимо считаешь декартовым произведением
Выбрать * ИЗ А LEFT JOIN A По ИСТИНА
А я подразумеваю:
Выбрать * ИЗ А LEFT JOIN A По любое условие.

(89) тогда и в ЦВсе условия надо добавлять, жду готовый запрос в общем

(92) а надо было учиться, чтобы знать что такое "декартово произведение"

Успокойтесь вы все..... ПРАВИЛЬНЫЙ ВАРИАНТ - одна строка кода условия

ВЫБРАТЬ ПЕРВЫЕ 1

ГДЕ ЦеныКрайние.Цена <> ЦеныНоменклатуры.Цена

УПОРЯДОЧИТЬ ПО Период УБЫВ

(95) Жаль, что нет ИЗ, а так бы сработало

попробуй так (у меня сейчас негде проверить, пишу без 1с, по этому там ошибок много)

ВЫБРАТЬ различные
    р.Номенклатура как номенклатура,
    Макс(р.Период) КАК Период
поместить ВТ1
ИЗ
РегистрСведений.ЦеныНоменклатуры КАК р
индексировать по номенклатура
группировать по р.Номенклатура;
ВЫБРАТЬ различные
    р.Номенклатура как номенклатура,
    Макс(р.Период) КАК Период
поместить ВТ2
ИЗ
РегистрСведений.ЦеныНоменклатуры КАК р
левое соединение ВТ1
по р.номенклатура = вт1.номенклатура и вт1.период > р.период
индексировать по номенклатура
группировать по р.Номенклатура;
и дальше 2 джойна регистром цен по номенклатуре+периоду из ВТ

(97) +
по любому будет быстрее сабжа

(97)
Различные зачем? )

(97)
Тоже грязь из (0) глаз режет? )

(92)
"А я подразумеваю:
Выбрать * ИЗ А LEFT JOIN A По любое условие."

Вот если любое условие кроме "Истина", то на мой ИМХО уже не декартово.
Но я не уверен. В школе плохо учился, да и не гений я.

(97) А какой смысл получать получать максимум по всей таблице если есть итоги?

(92)
Волшебника спроси, он любит мудростью делиться.
Мне лень. Да я и не уверен, что всегда прав. Просто действую как знаю.

(103) Лучше спросите СвинТуза. Он всё знает.

(103)
Не я туповат. С тобой как то общался.
Производишь. Я если бы не был ленив тоже бы был ничего.

(104)
Я обычно при возникновении проблемы начитываю.
Так плохо все помню.

Есть энциклопедисты. Это не я )

(101) это буквоедство, дружок. Есть такое

(107)
Невежество лучше?)
Есть общепринятые определения. Ты можешь думать по своему.
Минус в том что большинство людей тебя не поймет.

У нас свободная страна.
Стой на своем, если не больно. )))

(107)

Быстрее всего будет выгрести весь этот регистр целиком и польностью - а в выборке вывести только то что надо

(107)
Есть люди, которые не боятся показать свое невежество.
Я понимаю.

(107)
У тебя же пачка сертификатов?
Не покупал? Подарили? )
Зачем ты тут это все постишь? )

(97)
ВЫБРАТЬ
    ЦеныНоменклатурыСрезПоследних.Период КАК Период,
    ЦеныНоменклатурыСрезПоследних.Номенклатура КАК Номенклатура
ПОМЕСТИТЬ ВТ1
ИЗ
    РегистрСведений.ЦеныНоменклатуры.СрезПоследних(НЕОПРЕДЕЛЕНО) КАК ЦеныНоменклатурыСрезПоследних

+(110) на 3000 товаров такой отчет я думаю будет делаться 1 секунду

(0) Вот что такое неподдельный гуру-тест для программиста 1С, а не то что вчера запостил юзер TormozIT! Тема рулит!

пока так

ВЫБРАТЬ
    ТаблицаПериодов.Номенклатура КАК Номенклатура,
    ТаблицаПериодов.ПослПериод КАК ПослПериод,
    ПослЦеныНоменклатуры.Цена КАК ПослЦена,
    ТаблицаПериодов.ПредПериод КАК ПредПериод,
    ПредЦеныНоменклатуры.Цена КАК ПредЦена
ИЗ
    (ВЫБРАТЬ
        ЦеныНоменклатуры.Номенклатура КАК Номенклатура,
        МАКСИМУМ(ПредЦены.Период) КАК ПредПериод,
        ЦеныНоменклатуры.Период КАК ПослПериод
    ИЗ
        РегистрСведений.ЦеныНоменклатуры.СрезПоследних(, ВидЦены = &ВидЦены) КАК ЦеныНоменклатуры
            ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ПредЦены
            ПО ЦеныНоменклатуры.Номенклатура = ПредЦены.Номенклатура
                И (ПредЦены.ВидЦены = &ВидЦены)
                И ЦеныНоменклатуры.Период > ПредЦены.Период
                И ЦеныНоменклатуры.Цена <> ПредЦены.Цена
    
    СГРУППИРОВАТЬ ПО
        ЦеныНоменклатуры.Номенклатура,
        ЦеныНоменклатуры.Период) КАК ТаблицаПериодов
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ПредЦеныНоменклатуры
        ПО (ТаблицаПериодов.Номенклатура = ПредЦеныНоменклатуры.Номенклатура)
            И (ПредЦеныНоменклатуры.ВидЦены = &ВидЦены)
            И (ПредЦеныНоменклатуры.Период = ТаблицаПериодов.ПредПериод)
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ПослЦеныНоменклатуры
        ПО (ТаблицаПериодов.Номенклатура = ПослЦеныНоменклатуры.Номенклатура)
            И (ПослЦеныНоменклатуры.ВидЦены = &ВидЦены)
            И (ПослЦеныНоменклатуры.Период = ТаблицаПериодов.ПослПериод)

Рубятки хватит дрочить регистр.

У Фиксина там 3к товаров...

Даже если бы было 100к.

Быстрее всего будет это выгрести весь регистр без среза. с нужными сортировками. ну и еще можно период сделать МЕЖДУ.

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

Так как это регистр сведений - для него пофигу сколько там данных. хоть миллион.

Я думаю юзера вообще хрен интересует какие цены были год назад. Я вообще обработку написал удаления старых цен.

Самое тормозное будет в этом деле будет на удивление

ТаблицаОтчета.Вывести(Секция);

тормознее запроса на 100к товаров.

(119) выводи не построчно, а группами по 3 например

(118) Бывают огромные регистры цен даже на небольшом периоде. 100к товаров и несколько видов цен, которые пересчитываются ежедневно.
(119) это то да

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

(121) как говорят преподаватели в учебном центре 1С - всегда есть компромисс.

Если вы видите что это не принесет время - то можно использовать.

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

(121) сделай регистрацию только изменений. нафига каждый день фигачить однно и тоже.

(116) Это изнасилование оптимизатора запроса. :)

(125) В том и дело что не одно и то же

(127) тут фузина с ее декларативными триггерами была бы как нельзя кстати.

(128) >тут фузина с ее декларативными триггерами была бы как нельзя кстати

Ах, если бы сбылась моя мечта,
Какая жизнь настала бы тогда,
Ах, если бы мечта сбылась,
Какая жизнь тогда бы началась.

Ах, если бы, ах, если бы, не жизнь была б, а песня бы,
Ах, если бы, ах, если бы, не жизнь была б, а песня бы,
Ах, если бы, ах, если бы, не жизнь была б, а песня бы,
Ах, если бы, ах, если бы, не жизнь была б, а песня бы.

© мультик про Летучий корабль

(128) ну расскажи нам, что такое "декларативные триггеры"

(97) так же бы сделал через ВТ

(130) у клиентов г1с триггер только один - ЖАДНОСТЬ!

Вместо того чтобы базу в порядок привести. Чтобы ситуаций типа цена 10;20;20; не было Простейшей проверкой что если цена не менялась ее не пишем, народ запрос пишет который на 2 порядка медленнее работает. Как итог база пухнет, запрос тормозит.

(133) это лишнее.

(133) Писать надо всё, потому что отмена проведения предыдущего документа не должна влиять на более позднюю установку цен

Подрихтовал чутка запрос, теперь выглядит так:


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


Это уже то, что пошло в продакшн.

(136)ИЗ
    РегистрСведений.ЦеныНоменклатуры.СрезПоследних(, ВидЦены = &ВидЦены) КАК ЦТекущие
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦПрошлые
        ПО (ЦПрошлые.ВидЦены = &ВидЦены)
            И (ЦПрошлые.Номенклатура = ЦТекущие.Номенклатура)
            И (ЦПрошлые.Период В
                (ВЫБРАТЬ
                    МАКСИМУМ(Ц.Период)
                ИЗ
                    РегистрСведений.ЦеныНоменклатуры КАК Ц
                ГДЕ
                    Ц.Номенклатура = ЦТекущие.Номенклатура
                    И Ц.ВидЦены = &ВидЦены
                    И Ц.Цена <> ЦТекущие.Цена
                    И Ц.Период < ЦТекущие.Период))

Не проверял, но разве доступны поля из вышестояшего соединения(ЦТекущие) во вложенном подзапросе?

(137)Отбой - тормознул, всё ок.

(136) И что тут интересного? Обычный запрос. Решение в лоб, без изюминки. Может я не осознал гениальности замысла?

(139) исходя и того что тема заведена 1 числа, типа найденное решение 5 числа поставлено в продакшн.

Итого 5 дней работы, по 4 часа в день, по 2000 час. Гений заработал минимум 40 тысяч за этот запрос

(140) Ну, способность Фиксина зарабатывать некоторые деньги под сомнение не ставится ) Заглянул на мисту после долгого отсутствия, ожидал чего-то интересного. Оказалось, все по прежнему.

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

(140) хошь сказать, что наш гурий один запрос писал несколько дней?

(140) неа. я там работаю после 19, когда юзвери уходят, ну можно в принципе, на копии дома делать. на выходных тоже не работал. Просто руки дошли.

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

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

(145) и че, временне таблицы не зависят от размера регистра в этой задаче? гггг

(146) учись, и всё сам поймёшь