Вход | Регистрация


1С:Предприятие :: 1С:Предприятие 8 общая

Выборка из регистра накоплений

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

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

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

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

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

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

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

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

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

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

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

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


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует