Доброго времени суток! Есть достаточно простой вопрос, но... не доходит. Есть вот такой регистр: https://api.monosnap.com/image/download?id=Sp4nYRzndHs40JJoIB0CREvlmKIryn и есть список номенклатуры в запросе, надо получить для каждой номенклатуры контрагента с последней записью(максимальным полем период), пробовал группировать по полю период с функцией максимум, но тогда контрагент попадает в группировочные поля и я получаю всех контрагентов.

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

(0) открой для себя "Выбрать ПЕРВЫЕ 1" и "УПОРЯДОЧИТЬ ПО"

(1) + Период и ссылка в соединении.

(2)И получи одну запись на всю номенклатуру?

(1)А если будет два документа одинаковым периодом? Будем считать погрешностью? :)

(3) Ссылка = Ссылка регистратора

(4) ага)
(0) а такаой?

ВЫБРАТЬ РАЗЛИЧНЫЕ
    МАКСИМУМ(Закупки.Период) КАК Период,
    Закупки.Номенклатура,
    Закупки.Контрагент
ИЗ
    РегистрНакопления.Закупки КАК Закупки

СГРУППИРОВАТЬ ПО
    Закупки.Номенклатура,
    Закупки.Контрагент

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

(7) нет, такой не пойдёт(

(5) Да, может такое быть. Тогда вложенный запрос группируем:  Период МАКС, Регистратор МАКС :)

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

повисает на небольшом списке позиций(позиций 200) отъедая 2 гига памяти

Зачем здесь справочник в соединении? Попробуй обратиться к записям регистра.

(10) Если я правильно понял задачу, то нужно еще добавить в соединение Товар и Поставщики поле Номенклатура.

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


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


(11) Видимо, ему нужны данные по всем номенклатурам, даже если по ним не было поставок. Если такое не нужно, то действительно справочник Номенклатура не нужен в запросе :)

(12)Такое не нужно, у меня есть список номенклатуры и мне надо для него получить (0)

+(13)хотя нет ) наврал, нужно на выходе получить список номенклатуры и контрагентов в идеале

(10) Сразу 2 максимума неверно в принципе.
Такая пара может не найтись.

ВЫБРАТЬ
                МАКСИМУМ(Закупки.Период) КАК Период,
                Закупки.Номенклатура КАК Номенклатура,
                МАКСИМУМ(Закупки.Регистратор) КАК Регистратор

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

(15)Действительно, что то выпадает

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

(0) Регистр накопления для этого не предназначен. Нельзя ли добавить регистр сведений ? Или конфа типовая?

(18) можно
(19) чего?

(20) я имею ввиду на больших объемах данных будут тормоза

(20) выбрать то можно извратиться, но потом будет решать другие задачи связанные с производительностью

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

(21) (22) выдыхай, в (0) задача на 10 минут

(23) ага, и в оборотах закупки.Обороты(, тут условия по таблице 1) ты период не собираешься указывать?

(17) Сделай вложенный запрос с максимумом по дате и группировкой по регистратору, затем этот вложенный запрос максимум по регистратору. И потом еще его соединяем с таблицей движений :)

+(23) если список позиций в &СписокНоменклатур большой, то лучше тоже в отдельную ВТ выбрать
(24) не собираюсь, конечно
(25) вложенные запросы - зло, у человека уже валится система

(25)Если буду в (12) просто делать соединение по периоду и номенклатуре(без регистратора) и даже если будет два документа с одной датой с точностью до секунды, то собственно я все равно получу одну запись которая будет с максимальным периодом то есть взять какую то одну из этих двух записей же надо все равно, что запрос и сделает? Или я туплю где то?

(10) Целый клубок ошибок... посмотри в книгу знаний 1с

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

(26) Вложенный запрос не зло, соединение с вложенными запросами - зло

(29)  учи теорию. у оборотного регистра будет индекс Измерение + Период, если проиндексировано нужное измерение ( в случае автора - Номенклатура). так что за всю таблицу - ты не прав.

(30) да там в (25) чел, имхо, троллит.

(26) "вложенные запросы - зло, у человека уже валится система"

Нужно отбор во вложенном запросе сделать, как в (12) и ничего валиться не будет. Кроме того валилось потому что не было в соединении в (10) стыковки по номенклатуре...

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

(33) >> к виртуальной таблице оборотов,
1. она физическая.
2. если измерение проиндесировано, то индекс: Период+Измерение. и он, скорее всего, будет задействован.
3. по поводу что система сама будет выборку делать из таблицы движений - ты путаешь с агрегатами, это отдельная тема.


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

(34) 1. она виртуальная
2. Индекс будет задействован, даже в том случае, если не проставить в конфигураторе, при условии, что регистр построен как на картинке. Скажите почему? Читайте теорию. Ну дело тут не в индексе, я уже выше писал
3. Мда, ничего я не путаю

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

(35) ты не расстраивайся, твоим знаниям сто лет в обед.
я серьезно. прости если задел чем.

1. она виртуальная - Имя таблицы будет AccumRgTn<номер>.
И это, ты никогда не задумывался, что делает "Пересчет итогов" ? виртуальные таблички рассчитывает? )
2. ты путаешь, наверное, с семеркой. Индекс, по умолчанию, для оборотов кластерный, для основной таблицы - по периоду, по регистратору, по проиндексированным измерениям.
>> добавить дополнительные объекты конфигурации
ага, регистр сведений )))
а потом проиндексировать его и получить тоже самое, что просто добавить индекс по номенклатуре )))

(35) про первый пункт. с фига ли она виртуальная?

+(37) ну и если измерение проиндексировано, то вполне сносно будет отрабатывать

(36) вы писали выше закупки.Обороты(, тут условия по таблице 1) - с фига ли она реальная ? объясните мне ?

(36) (2) если память не изменяет Период + измерения в порядке следования их в конфигурации. Может что в платформе поменялось? 7.7 никогда не увлекался

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

+(40) по умолчанию индексы так строятся в 8-ке

(41) вообще красота. а ничего, что это это соединение реальных таблиц регистра сведений по максимуму (ну если говорить про 8.2)?
(39) ну потому что в начале субд проверяется по какой период рассчитаны итоги. если они рассчитаны за искомый период, то берется таблица итогов регистра. если же нет, то берется таблица самого регистра. или я не прав?)

+(43) так что понятие "виртуальная" довольно таки условное

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

(40) (42) нет
(43) все верно, только если включить индекс по полю, которое хотим отбирать - то не важно что будет использоваться в данном случае. нам интересен сам индекс.

(45) и при этом ты же начал объяснять как система работает )

(46) так. стоп. вот не догоняю сейчас "не важно что будет использоваться в данном случае. нам интересен сам индекс.". в разрезе чего? индекс рн или связка рн и св?

(47) нафиг регистр сведений, он тут ничем не поможет.

я имею в виду в рамках задачи (0) - включаем индекс по измерению "Номенклатура" и у таблицы оборотов он будет как "номенклатура"+"Период". по нему и построится запрос.

(46) откуда инфа такая про индексы. Всегда все говорят что для таблицы оборотов Период + измерения. Объясни пожалуйста

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

(49) с курсов УЦ №3

+(49) Период + измерения - это кластерный и то он создается для полей, у которых включено "использование в итогах"

(49) и да, объясни откуда твоя инфа. просто интересно, откуда это заблуждение, что по первому измерению индекс автоматом.

(52) разве кластерный?

(54) да

(55) о какой таблице идет речь? таблице регистра или таблице оборотов регистра?

(56) таблицу оборотов, конечно, см (52), я ж про итоги пишу.

(53) я и не говорил что только по первому измерению. я говорил что по Период + все измерения. Откуда инфа? с форума Чистова, когда готовился была ветка обсуждения

(58) твои слова + (35) "2. Индекс будет задействован, даже в том случае, если не проставить в конфигураторе, при условии, что регистр построен как на картинке. "
тогда полный бред.
"у Чистова на форуме" - железный аргумент, че.

p.s. чтобы задействовать кластерный индекс - надо указать ВСЕ измерения которые в нем участвуют.

(59) вроде все правильно я там написал, открой книгу проф разработка стр. 718. "Если требуется получать итоги по одному измерению, которое не является первым, - следует его проиндексировать". Т.е. если мы делаем отбор Изм1 или Изм1 + Изм2 это эффективно, а когда Изм2 - это уже не эффективно.

+ (60) в этом случае изм2 нужно проиндексировать

>>p.s. чтобы задействовать кластерный индекс - надо указать ВСЕ измерения которые в нем участвуют.
вот это впервые слышу.

(60) (61) да ну, глупости какие-то. уже проверил бы давно, что это не так, а то упираешься на пустом месте.

(62) да забудь, после (60)

(63) мда, пытаюсь добиться правды, а ты опять за свое )). Почему в (60) глупости? Ты открывал книгу или нет? или просто пук в небо?

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

Не звезди. Это не я ошибаюсь, а ты или авторы книги. Посмотрел структуру регистра, по умолчанию создаются индексы "Period", "Fld1", "Fld2", ... "FldN". О чем мы выше говорили.
Сделал замер для запроса с отбором по первому полю. Далее проиндексировал это поле, сделал замер. Результаты не отличаются практически, я бы сказал что с установкой индекса время чуть больше.

(66) у тебя запрос по какой таблице выполнился?
телепатирую - по основной таблице

(67) по виртуальной конечно же

ну тогда у тебя там записей с гулькин нос.
ТЖ смотрел?

+ без индекса там фулл скан

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