Получить последнюю по дате запись из регистра накопления #719600

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

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

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

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

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

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

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

ага) а такаой?

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

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

что то вот такой запрос ВЫБРАТЬ     Товар.Ссылка,     Закупки.Контрагент ИЗ повисает на небольшом списке позиций(позиций 200) отъедая 2 гига памяти

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

Если я правильно понял задачу, то нужно еще добавить в соединение Товар и Поставщики поле Номенклатура. И для ускорения запроса можно в таблицу Поставщики добавить условие с отбором номенклатуры: Видимо, ему нужны данные по всем номенклатурам, даже если по ним не было поставок. Если такое не нужно, то действительно справочник Номенклатура не нужен в запросе :)

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

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

Сразу 2 максимума неверно в принципе. Такая пара может не найтись. ВЫБРАТЬ

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

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

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

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

можно чего?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

с курсов УЦ №3

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

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

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

да

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

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

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

твои слова + "2. Индекс будет задействован, даже в том случае, если не проставить в конфигураторе, при условии, что регистр построен как на картинке. " тогда полный бред. "у Чистова на форуме" - железный аргумент, че. p.s. чтобы задействовать кластерный индекс - надо указать ВСЕ измерения которые в нем участвуют.

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

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

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

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

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

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

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

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

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

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

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

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