Имя: Пароль:
1C
1С v8
Получить последнюю по дате запись из регистра накопления
0 Web00001
 
10.09.14
08:12
Доброго времени суток! Есть достаточно простой вопрос, но... не доходит. Есть вот такой регистр: https://api.monosnap.com/image/download?id=Sp4nYRzndHs40JJoIB0CREvlmKIryn и есть список номенклатуры в запросе, надо получить для каждой номенклатуры контрагента с последней записью(максимальным полем период), пробовал группировать по полю период с функцией максимум, но тогда контрагент попадает в группировочные поля и я получаю всех контрагентов.
1 Фокусник
 
10.09.14
08:15
(0) Вложенный запрос: максимум по периоду (без контрагента), поэтом этот вложенный запрос соединить с движениями регистра: соединять по периоду
2 Azverin
 
10.09.14
08:17
(0) открой для себя "Выбрать ПЕРВЫЕ 1" и "УПОРЯДОЧИТЬ ПО"
3 toluol
 
10.09.14
08:17
(1) + Период и ссылка в соединении.
4 Web00001
 
10.09.14
08:18
(2)И получи одну запись на всю номенклатуру?
5 Web00001
 
10.09.14
08:20
(1)А если будет два документа одинаковым периодом? Будем считать погрешностью? :)
6 toluol
 
10.09.14
08:23
(3) Ссылка = Ссылка регистратора
7 Azverin
 
10.09.14
08:29
(4) ага)
(0) а такаой?

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

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

УПОРЯДОЧИТЬ ПО
    Период УБЫВ
8 Azverin
 
10.09.14
08:32
(7) нет, такой не пойдёт(
9 Фокусник
 
10.09.14
08:34
(5) Да, может такое быть. Тогда вложенный запрос группируем:  Период МАКС, Регистратор МАКС :)
10 Web00001
 
10.09.14
08:44
что то вот такой запрос
ВЫБРАТЬ
    Товар.Ссылка,
    Закупки.Контрагент
ИЗ
    Справочник.Номенклатура КАК Товар
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.Закупки КАК Закупки
            ВНУТРЕННЕЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
                МАКСИМУМ(Закупки.Период) КАК Период,
                Закупки.Номенклатура КАК Номенклатура,
                МАКСИМУМ(Закупки.Регистратор) КАК Регистратор
            ИЗ
                РегистрНакопления.Закупки КАК Закупки
            
            СГРУППИРОВАТЬ ПО
                Закупки.Номенклатура) КАК Поставщики
            ПО Закупки.Регистратор = Поставщики.Регистратор
                И Закупки.Период = Поставщики.Период
        ПО Товар.Ссылка = Закупки.Номенклатура
ГДЕ
    Товар.Ссылка В(&СписокНоменклатур)

повисает на небольшом списке позиций(позиций 200) отъедая 2 гига памяти
11 Мимохожий Однако
 
10.09.14
08:50
Зачем здесь справочник в соединении? Попробуй обратиться к записям регистра.
12 Фокусник
 
10.09.14
08:55
(10) Если я правильно понял задачу, то нужно еще добавить в соединение Товар и Поставщики поле Номенклатура.

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


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


(11) Видимо, ему нужны данные по всем номенклатурам, даже если по ним не было поставок. Если такое не нужно, то действительно справочник Номенклатура не нужен в запросе :)
13 Web00001
 
10.09.14
08:57
(12)Такое не нужно, у меня есть список номенклатуры и мне надо для него получить (0)
14 Web00001
 
10.09.14
08:58
+(13)хотя нет ) наврал, нужно на выходе получить список номенклатуры и контрагентов в идеале
15 alle68
 
10.09.14
09:02
(10) Сразу 2 максимума неверно в принципе.
Такая пара может не найтись.

ВЫБРАТЬ
                МАКСИМУМ(Закупки.Период) КАК Период,
                Закупки.Номенклатура КАК Номенклатура,
                МАКСИМУМ(Закупки.Регистратор) КАК Регистратор
16 Мимохожий Однако
 
10.09.14
09:19
Тогда вариант (2) с запросом к регистру без всяких справочников. Нельзя получить запись, если её никогда не было.
17 Web00001
 
10.09.14
09:53
(15)Действительно, что то выпадает
18 Web00001
 
10.09.14
09:57
Засада без запроса в цикле, ничего не получится как я понял.
19 DefMB
 
10.09.14
10:06
(0) Регистр накопления для этого не предназначен. Нельзя ли добавить регистр сведений ? Или конфа типовая?
20 sf
 
10.09.14
10:07
(18) можно
(19) чего?
21 DefMB
 
10.09.14
10:08
(20) я имею ввиду на больших объемах данных будут тормоза
22 DefMB
 
10.09.14
10:09
(20) выбрать то можно извратиться, но потом будет решать другие задачи связанные с производительностью
23 sf
 
10.09.14
10:11
(0)
1. Создаешь временную таблицу вида Номенклатура - максимальная дата поступления
2. из закупки.Обороты(, тут условия по таблице 1) выбираешь все что нужно

(21) (22) выдыхай, в (0) задача на 10 минут
24 DefMB
 
10.09.14
10:14
(23) ага, и в оборотах закупки.Обороты(, тут условия по таблице 1) ты период не собираешься указывать?
25 Фокусник
 
10.09.14
10:17
(17) Сделай вложенный запрос с максимумом по дате и группировкой по регистратору, затем этот вложенный запрос максимум по регистратору. И потом еще его соединяем с таблицей движений :)
26 sf
 
10.09.14
10:22
+(23) если список позиций в &СписокНоменклатур большой, то лучше тоже в отдельную ВТ выбрать
(24) не собираюсь, конечно
(25) вложенные запросы - зло, у человека уже валится система
27 Web00001
 
10.09.14
10:25
(25)Если буду в (12) просто делать соединение по периоду и номенклатуре(без регистратора) и даже если будет два документа с одной датой с точностью до секунды, то собственно я все равно получу одну запись которая будет с максимальным периодом то есть взять какую то одну из этих двух записей же надо все равно, что запрос и сделает? Или я туплю где то?
28 Ник второй
 
10.09.14
10:27
(10) Целый клубок ошибок... посмотри в книгу знаний 1с
29 DefMB
 
10.09.14
10:27
(26) в том то и проблема будет , если период не указывать будет вся таблица выбираться. Видимо вы не сталкивались с этим
30 Ник второй
 
10.09.14
10:29
(26) Вложенный запрос не зло, соединение с вложенными запросами - зло
31 sf
 
10.09.14
10:32
(29)  учи теорию. у оборотного регистра будет индекс Измерение + Период, если проиндексировано нужное измерение ( в случае автора - Номенклатура). так что за всю таблицу - ты не прав.

(30) да там в (25) чел, имхо, троллит.
32 Фокусник
 
10.09.14
10:56
(26) "вложенные запросы - зло, у человека уже валится система"

Нужно отбор во вложенном запросе сделать, как в (12) и ничего валиться не будет. Кроме того валилось потому что не было в соединении в (10) стыковки по номенклатуре...
33 DefMB
 
10.09.14
11:12
(31) да не в индексации дело, представьте у вас миллионы записей с одинаковой номенклатурой, у вас все эти записи будут выбраны, если вы используете виртуальную таблицу без отбора по периоду.
Кроме того, когда обращаемся к виртуальной таблице оборотов, системы пытается получить итоги и построить запрос SQL оптимальным способом. В вашем таком запросе с периодичностью , будет использована таблица движений, это приведет к снижению производительности.
Учи теорию!
34 sf
 
10.09.14
11:40
(33) >> к виртуальной таблице оборотов,
1. она физическая.
2. если измерение проиндесировано, то индекс: Период+Измерение. и он, скорее всего, будет задействован.
3. по поводу что система сама будет выборку делать из таблицы движений - ты путаешь с агрегатами, это отдельная тема.


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

p.s.  уже выше писал, если есть возможность, в таких случаях лучше добавить дополнительные объекты конфигурации
36 sf
 
10.09.14
12:12
(35) ты не расстраивайся, твоим знаниям сто лет в обед.
я серьезно. прости если задел чем.

1. она виртуальная - Имя таблицы будет AccumRgTn<номер>.
И это, ты никогда не задумывался, что делает "Пересчет итогов" ? виртуальные таблички рассчитывает? )
2. ты путаешь, наверное, с семеркой. Индекс, по умолчанию, для оборотов кластерный, для основной таблицы - по периоду, по регистратору, по проиндексированным измерениям.
>> добавить дополнительные объекты конфигурации
ага, регистр сведений )))
а потом проиндексировать его и получить тоже самое, что просто добавить индекс по номенклатуре )))
37 Кир Пластелинин
 
10.09.14
12:14
(35) про первый пункт. с фига ли она виртуальная?
38 Кир Пластелинин
 
10.09.14
12:15
+(37) ну и если измерение проиндексировано, то вполне сносно будет отрабатывать
39 DefMB
 
10.09.14
12:27
(36) вы писали выше закупки.Обороты(, тут условия по таблице 1) - с фига ли она реальная ? объясните мне ?
40 DefMB
 
10.09.14
12:33
(36) (2) если память не изменяет Период + измерения в порядке следования их в конфигурации. Может что в платформе поменялось? 7.7 никогда не увлекался
41 DefMB
 
10.09.14
12:35
(36)>>а потом проиндексировать его и получить тоже самое, что просто добавить индекс по номенклатуре )))
нет, взять просто срез. последних ))
42 DefMB
 
10.09.14
12:37
+(40) по умолчанию индексы так строятся в 8-ке
43 Кир Пластелинин
 
10.09.14
12:41
(41) вообще красота. а ничего, что это это соединение реальных таблиц регистра сведений по максимуму (ну если говорить про 8.2)?
(39) ну потому что в начале субд проверяется по какой период рассчитаны итоги. если они рассчитаны за искомый период, то берется таблица итогов регистра. если же нет, то берется таблица самого регистра. или я не прав?)
44 Кир Пластелинин
 
10.09.14
12:44
+(43) так что понятие "виртуальная" довольно таки условное
45 DefMB
 
10.09.14
12:44
(43) да, вы правы, но это называется обращение к виртуальной, а что система там дальше делает это уже другой уровень понимания ))
46 sf
 
10.09.14
12:47
(40) (42) нет
(43) все верно, только если включить индекс по полю, которое хотим отбирать - то не важно что будет использоваться в данном случае. нам интересен сам индекс.

(45) и при этом ты же начал объяснять как система работает )
47 Кир Пластелинин
 
10.09.14
12:49
(46) так. стоп. вот не догоняю сейчас "не важно что будет использоваться в данном случае. нам интересен сам индекс.". в разрезе чего? индекс рн или связка рн и св?
48 sf
 
10.09.14
12:56
(47) нафиг регистр сведений, он тут ничем не поможет.

я имею в виду в рамках задачи (0) - включаем индекс по измерению "Номенклатура" и у таблицы оборотов он будет как "номенклатура"+"Период". по нему и построится запрос.
49 DefMB
 
10.09.14
12:56
(46) откуда инфа такая про индексы. Всегда все говорят что для таблицы оборотов Период + измерения. Объясни пожалуйста
50 Кир Пластелинин
 
10.09.14
12:58
(48) ну касательно рсв - согласен. мало того, что это создание лишних сущностей в базе, так и профит сомнительный.
51 sf
 
10.09.14
13:03
(49) с курсов УЦ №3
52 sf
 
10.09.14
13:05
+(49) Период + измерения - это кластерный и то он создается для полей, у которых включено "использование в итогах"
53 sf
 
10.09.14
13:06
(49) и да, объясни откуда твоя инфа. просто интересно, откуда это заблуждение, что по первому измерению индекс автоматом.
54 Кир Пластелинин
 
10.09.14
13:08
(52) разве кластерный?
55 sf
 
10.09.14
13:08
(54) да
56 Кир Пластелинин
 
10.09.14
13:10
(55) о какой таблице идет речь? таблице регистра или таблице оборотов регистра?
57 sf
 
10.09.14
13:13
(56) таблицу оборотов, конечно, см (52), я ж про итоги пишу.
58 DefMB
 
10.09.14
13:27
(53) я и не говорил что только по первому измерению. я говорил что по Период + все измерения. Откуда инфа? с форума Чистова, когда готовился была ветка обсуждения
59 sf
 
10.09.14
13:37
(58) твои слова + (35) "2. Индекс будет задействован, даже в том случае, если не проставить в конфигураторе, при условии, что регистр построен как на картинке. "
тогда полный бред.
"у Чистова на форуме" - железный аргумент, че.

p.s. чтобы задействовать кластерный индекс - надо указать ВСЕ измерения которые в нем участвуют.
60 DefMB
 
10.09.14
13:49
(59) вроде все правильно я там написал, открой книгу проф разработка стр. 718. "Если требуется получать итоги по одному измерению, которое не является первым, - следует его проиндексировать". Т.е. если мы делаем отбор Изм1 или Изм1 + Изм2 это эффективно, а когда Изм2 - это уже не эффективно.
61 DefMB
 
10.09.14
13:50
+ (60) в этом случае изм2 нужно проиндексировать
62 DefMB
 
10.09.14
13:50
>>p.s. чтобы задействовать кластерный индекс - надо указать ВСЕ измерения которые в нем участвуют.
вот это впервые слышу.
63 sf
 
10.09.14
15:39
(60) (61) да ну, глупости какие-то. уже проверил бы давно, что это не так, а то упираешься на пустом месте.

(62) да забудь, после (60)
64 DefMB
 
10.09.14
15:58
(63) мда, пытаюсь добиться правды, а ты опять за свое )). Почему в (60) глупости? Ты открывал книгу или нет? или просто пук в небо?
65 sf
 
10.09.14
16:04
(64) да я даже технологический журнал специально посмотрел и индексы проверил в обеих табличках (основной и оборотов), со снятым/включенным индексом. ты ошибаешься нехило )
66 DefMB
 
10.09.14
16:38
Не звезди. Это не я ошибаюсь, а ты или авторы книги. Посмотрел структуру регистра, по умолчанию создаются индексы "Period", "Fld1", "Fld2", ... "FldN". О чем мы выше говорили.
Сделал замер для запроса с отбором по первому полю. Далее проиндексировал это поле, сделал замер. Результаты не отличаются практически, я бы сказал что с установкой индекса время чуть больше.
67 sf
 
10.09.14
16:42
(66) у тебя запрос по какой таблице выполнился?
телепатирую - по основной таблице
68 DefMB
 
10.09.14
16:43
(67) по виртуальной конечно же
69 sf
 
10.09.14
16:45
ну тогда у тебя там записей с гулькин нос.
ТЖ смотрел?
70 sf
 
10.09.14
16:46
+ без индекса там фулл скан
71 Кир Пластелинин
 
10.09.14
17:29
(66) ну тут как бы много параметров влияющих на быстродействие. на примере скуля - актуальность статистики, фрагментированность индексов (хотя в случае, если индекс только создан, то фрагментации у него не должно быть). тут еще нужно профайлером план запроса смотреть.
Требовать и эффективности, и гибкости от одной и той же программы — все равно, что искать очаровательную и скромную жену... по-видимому, нам следует остановиться на чем-то одном из двух. Фредерик Брукс-младший