Имя: Пароль:
   
1C
1С v8
Выборка из регистра накоплений
0 kupreeff
 
10.04.18
18:57
Имеется регистр накопления. Измерения a(справочник),б(справочник),в(число) и некий ресурс.
если движения, например
а1,б1,0 100
а1,б1,1 150
а2,б2,1 300
а3,б3,0 400
а3,б3,2 600
Как выбрать движения с максимальным значением регистра в по одинаковой паре а,б?
Т.е. в результате будут:
а1,б1,1 150
а2,б2,1 300
а3,б3,2 600
Задача (хотя это не суть, но для полноты картины скажу)связана с движениями по некоторому бюджету, по которому делаются корректировки, т.е. регистр в - номер корректировки, а - организация, б - статья бюджета. Соответственно в отчет по бюджету нужно брать значения по максимально проведенной корректировке.
Буду премного благодарен за подсказку! Спасибо.
1 Малыш Джон
 
10.04.18
19:11
обороты; сгруппировать по а,б; максимум
2 kupreeff
 
10.04.18
19:13
(1) Максимум где? в СГРУППИРОВАТЬ?
3 shuhard
 
10.04.18
19:14
(2) ну да, имеющие
4 kupreeff
 
10.04.18
19:20
Пишу
ВЫБРАТЬ
а,б,в из Регистр.Бюджет.Обороты
СГРУППИРОВАТЬ ПО
а,б,МАКСИМУМ(в)

Ошибка: операция не разрешена в предложении СГРУППИРОВАТЬ
5 shuhard
 
10.04.18
19:22
(4) ещё раз
имеющие
6 kupreeff
 
10.04.18
19:29
(5) СГруппировать По
а,б
ИМЕЮЩИЕ (Максимум(в))
Операция не разрешена в предложении ИМЕЮЩИЕ (
я эту директиву ни разу не использовал, вот не знаю, куда ее правильно вставить
7 kupreeff
 
10.04.18
19:36
ВЫБРАТЬ
а,б, МАКСИМУМ(в) КАК в
ИЗ Регистр.Бюджет.Обороты КАК Бюджета
СГРУППИРОВАТЬ ПО
Бюджет.а,Бюджет.б,Бюджет.в
ИМЕЮЩИЕ (Бюджет.в=в)
выдает только
а3,б3,2
8 VitShvets
 
10.04.18
19:38
А так?
ВЫБРАТЬ
а,б, МАКСИМУМ(в) КАК в
ИЗ Регистр.Бюджет.Обороты КАК Бюджет
СГРУППИРОВАТЬ ПО
Бюджет.а,Бюджет.б
9 unregistered
 
10.04.18
19:39
Вот что значит криво спроектированный регистр....
10 kupreeff
 
10.04.18
19:45
(8) не подходит, увы, все попадает
(9) ну может быть, может быть, ну а как иначе?
11 unregistered
 
10.04.18
19:47
ВЫБРАТЬ
   Бюджет.А КАК А,
   Бюджет.Б КАК Б,
   Бюджет.В КАК В,
   Бюджет.Ресурс КАК Ресурс
ИЗ
   РегистрНакопления.Бюджет КАК Бюджет
     ВНУТРЕННЕЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
                              Бюджет.А КАК А,
                              Бюджет.Б КАК Б,
                              МАКСИМУМ(Бюджет.В) КАК В
                            ИЗ
                              РегистрНакопления.Бюджет КАК Бюджет
                            СГРУППИРОВАТЬ ПО
                              Бюджет.А,
                              Бюджет.Б) КАК ВложенныйЗапрос
        ПО Бюджет.А = ВложенныйЗапрос.А
            И Бюджет.Б = ВложенныйЗапрос.Б
            И Бюджет.В = ВложенныйЗапрос.В
12 Малыш Джон
 
10.04.18
19:47
(10) как это "все пропадает" ???
в (8) отборов никаких нет, только по каждой паре а,б выбирается максимум (в)...
13 kupreeff
 
10.04.18
19:49
(12) попадает, а не пропадает)
(11) пробую....
14 Малыш Джон
 
10.04.18
19:49
(11) не учи плохому)

ВЫБРАТЬ
  БюджетОбороты.а,
  БюджетОбороты.б,
  МАКСИМУМ(Ресурс)
ИЗ
  РегистрНакопления.Бюджет.Обороты КАК БюджетОбороты
СГРУППИРОВАТЬ
  БюджетОбороты.а,
  БюджетОбороты.б
15 kupreeff
 
10.04.18
19:50
(14) намекаете, вернее прямо говорите, что надо ресурсом сделать номер корректировки?
16 Малыш Джон
 
10.04.18
19:50
(13) Так тебе нужно самое максимальное значение из всех пар?
17 VitShvets
 
10.04.18
19:51
(12), (14) Не решает задачу такой запрос. Как я понял, нужно получить значения А-Б-В при максимальном Ресурсе. В (11) правильно. Мне интересно, куда в (3) предлагается "ИМЕЮЩИЕ" затолкать.
18 kupreeff
 
10.04.18
19:51
(15) по сути да, из всех ни то, чтоб пар, разные комбинации организаций (а) и статей (б), но для одинакового сочетания надо выбрать с максимальным значением В
19 Малыш Джон
 
10.04.18
19:52
(15) нет, я просто не знаю, какой буквой ты обозначаешь ресурс. ну... который 100,150,300,400...
20 Малыш Джон
 
10.04.18
19:53
(18) если для  КАЖДОЙ пары максимальное значение - тогда (8) (14)
21 kupreeff
 
10.04.18
19:53
(19) это я привел как пример сумм в бюджете, номер корректировки у меня в измерении пока что сидит
22 unregistered
 
10.04.18
19:53
(10) >> ну а как иначе?

Не вижу причин почему нельзя сделать нормально.
1. Измерение числового типа. Это не то чтобы прямо преступление, но 1С крайне рекомендует делать измерения простых типов (число, строка, дата, булево).
2. Я не знаю что хранит этот регистр. Но бытовая логика подсказывает, что речь идет о величине планируемых доходов, расходов или движений. Если вы храните планируемые величины (то есть некое состояние некоего ресурса), то почему это не регистр сведений. Ведь именно регистры сведений предназначены для хранения показателей состояния. Если же вам прям необходимо, чтобы это был регистр накопления, то в ресурсе тогда надо хранить не состояние некой величины, а её изменение - приращение или уменьшение (оборот с плюсом или с минусом, если регистр оборотный). Во втором случае проблема решается тупым прямым запросом к оборотам (система сама проссумирует ресурс и получит результат на конечную дату).
23 Малыш Джон
 
10.04.18
19:54
(18) если макисимальное значение(ОДНО!)  из всех пар:

ВЫБРАТЬ
  МАКСИМУМ(Ресурс)
ИЗ
  РегистрНакопления.Бюджет.Обороты КАК БюджетОбороты
24 unregistered
 
10.04.18
19:54
(14) Ты не понял задачу автора. Перечитай внимательно (0)
25 unregistered
 
10.04.18
19:54
(23) Ему МАКСИМУМ нужен не по ресурсу, а по ИЗМЕРЕНИЮ. Не тупи.
26 unregistered
 
10.04.18
19:56
(22)* крайне рекомендует НЕ делать
27 unregistered
 
10.04.18
19:57
(15) >> намекаете, вернее прямо говорите, что надо ресурсом сделать номер корректировки?

НЕТ!
И я такого не говорил.
28 VS-1976
 
10.04.18
19:58
(26) Только я бы к выборке присоединял бы левым РегистрНакопления.Бюджет КАК Бюджет
29 unregistered
 
10.04.18
20:00
(28) Смысла в левом соединении нет никакого. Во-первых, мы делаем запрос к одной и той же таблице. А, во-вторых, это исказит результат - нам же нужно "отсечь" записи где измерение "в" НЕ максимальное.
30 kupreeff
 
10.04.18
20:00
(14) ругается,"Поле не найдено".
31 Малыш Джон
 
10.04.18
20:01
(24) ты хочешь сказать, что код в (14) не даст результата как в (0) ?
32 Малыш Джон
 
10.04.18
20:02
+(31) ну, только что, номера корректировок отдельно придется вытаскивать
33 unregistered
 
10.04.18
20:03
(31) Конечно нет. Ты путаешь измерение и ресурс.
Автору нужен МАКСИМУМ по измерению "в". А ресурс наоборот - НЕ должен суммироваться.
34 Малыш Джон
 
10.04.18
20:04
+(33) ахххаа, ну реально, затупил)
да, максимум по номеру корректировки, а потом соединять по нему и измерениям с регистром и вытаскивать ресурс
35 VS-1976
 
10.04.18
20:05
(29) Вера в великий оптимизатор?
Почему должно исказить результат?
И что что запрос к одной и той же таблице? Что кэш бесконечный?

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

   СГРУППИРОВАТЬ ПО
     Бюджет.А,
     Бюджет.Б) КАК ВложенныйЗапрос

   ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.Бюджет КАК Бюджет
        ПО Бюджет.А = ВложенныйЗапрос.А
            И Бюджет.Б = ВложенныйЗапрос.Б
            И Бюджет.В = ВложенныйЗапрос.В
36 unregistered
 
10.04.18
20:05
Если человеческим языком формулировать, то ему нужны данные по последним (МАКСИМАЛЬНЫМ) корректировкам.
37 unregistered
 
10.04.18
20:08
(35) При чем тут оптимизатор? В результате ЛЕВОГО соединения у тебя в итоге останутся ВСЕ записи из регистра. А автору надо ОТСЕЧЬ те, где номер корректировки (измерение "В") не максимальный. Отсечение реализуется внутренним соединением, а не левым.
38 VitShvets
 
10.04.18
20:10
+ к (35) inner join сиквел всяко быстрее отработает чем left join. Если регистр конский (миллионы записей), то лучше сделать выборку нужного во времянку с отборами, чем женить физику миллионную.
39 kupreeff
 
10.04.18
20:12
Ох, завтра на свежую голову опробую (11), т.е. внутреннее соединение. Ребят, всем большое спасибо за потраченное время, завтра подниму ветку с вашего позволения)
40 VS-1976
 
10.04.18
20:12
(38) Ну как бы соединение по индексу, если миллионные записи делать времянку на лямоны??? И чем inner join быстрее left join?
41 unregistered
 
10.04.18
20:23
Если уж говорить об оптимизации, то может иметь смысл такая форма этого же запроса:

ВЫБРАТЬ
   Бюджет.А КАК А,
   Бюджет.Б КАК Б,
   Бюджет.В КАК В,
   Бюджет.Ресурс КАК Ресурс
ИЗ
   РегистрНакопления.Бюджет КАК Бюджет
ГДЕ
   (Бюджет.А, Бюджет.Б, Бюджет.В) В
        (ВЫБРАТЬ
           Бюджет.А КАК А,
           Бюджет.Б КАК Б,
           МАКСИМУМ(Бюджет.В) КАК В
         ИЗ
           РегистрНакопления.Бюджет КАК Бюджет
         СГРУППИРОВАТЬ ПО
           Бюджет.А,
           Бюджет.Б)
42 VS-1976
 
10.04.18
20:25
(41) Это что-то свеженькое :) наверное недавно завезли...
43 unregistered
 
10.04.18
20:29
(42) Что именно?... Не понял.
44 VitShvets
 
10.04.18
20:32
(40) Времянку на миллионы бессмысленно делать, я написал про отборы. В нормальных живых задачах чаще всего, можно указать условия, когда из миллионной таблицы получаются сотни или тысячи нужных записей.

Когда сиквел умножает таблицы, то при inner он может умножить как левую на правую, так и наоборот. При левом соединении такого пространства для оптимизации нет. В итоге, если быть точнее, inner работает точно не медленнее left join. Но, тут больше надо смотреть на условие. По условию, в выборке не должно быть записи {а1,б1,0 100}, а при левом соединении она будет. Таки в (11) правильно, только я бы сделал бы в виде пакетного, а не вложенного запроса.
45 VS-1976
 
10.04.18
20:37
(44) С чего вдруг {а1,б1,0 100} при внутреннем не должно быть?
46 VS-1976
 
10.04.18
20:40
(45) Да не будет, но и при левом тоже не будет
47 VitShvets
 
10.04.18
20:52
(43) :) Не знакома видимо такая конструкция. Но правда, я так не пишу. Внутреннее соединение мне понятнее.
(46) Левое ухо тоже можно почесать правой ногой, только обычно так не делают.
48 VS-1976
 
10.04.18
20:55
(47) С точки зрения оптимизации, то этот запрос может уйти в таймаут. Подумай про (11) как будет выполняться запрос, а как будет выполняться запрос из (35) и какой из них будет быстрее
49 VitShvets
 
10.04.18
21:05
(48) С хр... Почему это запрос должен в таймаут уйти? Я голосую за inner join, но мне не нравится ни 35 ни тем более 11. Мой вариант пакетом:
1. Выборка из физики в ВТ_ЧерновыеДанные. Актуально если большая таблица с данными. Можно индексировать, но надо измерять.
2. Получение максимума Ресурса с группировкой по а и б из ВТ_ЧерновыеДанные. Складываем в ВТ_ВложенныйЗапрос.
3. Выборка из ВТ_ЧерновыеДанные с внутренним соединением ВТ_ВложенныйЗапрос по а, б и Ресурсу.

Если физика маленькая и прогноза по её росту нет, можно работать с регистром и времянку в п.1 не создавать.
50 VitShvets
 
10.04.18
21:06
(49) * но мне не нравится ни 11 ни тем более 35.
51 VS-1976
 
10.04.18
21:11
(50) (Бюджет.А, Бюджет.Б, Бюджет.В) В и во что же будет преобразовано это чудо в ANSI-SQL?
52 H A D G E H O G s
 
10.04.18
21:28
(49) ядская дичь
53 H A D G E H O G s
 
10.04.18
21:29
индекс не работает при соединении 2-х больших таблиц, пора бы это знать, забудьте про него.
54 smaharbA
 
10.04.18
21:30
Йожик превед.
Так малоли...
55 H A D G E H O G s
 
10.04.18
21:31
если группировка по 2 м первым измерениям крайне меньше исходной таблицы - ее можно загнать в ВТ и ВТ соединять с физической, ничего не индексируя.
иначе
(35)
56 smaharbA
 
10.04.18
21:32
Вы тут даже код банчите ?
57 Мимохожий Однако
 
10.04.18
21:32
Мне никогда не нравились измерения с типом число
58 Малыш Джон
 
10.04.18
22:04
(53) пруф или не было
59 VS-1976
 
10.04.18
22:07
(58) Он говорит что вероятнее всего оптимизатором будет выбран full scan, так как поиск в индексе может гораздо больше стоить.
60 H A D G E H O G s
 
10.04.18
22:09
(58) Давайте вы пораскинете мозгом, подумаете, как бы вы на месте разработчика БД соединяли 2 таблицы, и, вернувшись сюда, подтвердите мои слова.
61 tesseract
 
10.04.18
23:03
(60) Ага, особенно когда одна временная в оперативе и без индексов, а к ней пытаются присобачить физическую, и бедный план запроса говорит - "да идите в зад, я на всякий случай пошлю нахрен индекс и просканирую всю таблицу, все равно я не в курсе какие типы данных мне приедут во вложенном запросе".
62 H A D G E H O G s
 
10.04.18
23:04
(61) какой странный набор слов.
63 tesseract
 
10.04.18
23:05
(62) Я не разговаривал с профайлером, хотя он очень просил.
64 H A D G E H O G s
 
10.04.18
23:09
(63) постарайтесь научиться понимать его мотивацию.
65 tesseract
 
10.04.18
23:16
(64) Достаточно научился :-) Правда T-SQL уже подзабыл. Слоник лучше.
66 VS-1976
 
10.04.18
23:26
(65) До T-SQL 1С особо и не опускается
67 kupreeff
 
11.04.18
08:44
Ребят, доброе утро! Так с чего в итоге мне попробовать?) (11)?
68 kupreeff
 
11.04.18
08:53
Вроде бы (11) взлетело! Посмотрю на большЕм объеме данных. Миллионных записей не предвидится.
69 kupreeff
 
11.04.18
08:54
Спасибо всем за активную дискуссию, приятно, что вопрос не остался не замеченным. Отдельное спасибо автору (11).
Требовать и эффективности, и гибкости от одной и той же программы — все равно, что искать очаровательную и скромную жену... по-видимому, нам следует остановиться на чем-то одном из двух. Фредерик Брукс-младший