Имеется регистр накопления. Измерения 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) Максимум где? в СГРУППИРОВАТЬ?

(2) ну да, имеющие

Пишу
ВЫБРАТЬ
а,б,в из Регистр.Бюджет.Обороты
СГРУППИРОВАТЬ ПО
а,б,МАКСИМУМ(в)

Ошибка: операция не разрешена в предложении СГРУППИРОВАТЬ

(4) ещё раз
имеющие

(5) СГруппировать По
а,б
ИМЕЮЩИЕ (Максимум(в))
Операция не разрешена в предложении ИМЕЮЩИЕ (
я эту директиву ни разу не использовал, вот не знаю, куда ее правильно вставить

ВЫБРАТЬ
а,б, МАКСИМУМ(в) КАК в
ИЗ Регистр.Бюджет.Обороты КАК Бюджета
СГРУППИРОВАТЬ ПО
Бюджет.а,Бюджет.б,Бюджет.в
ИМЕЮЩИЕ (Бюджет.в=в)
выдает только
а3,б3,2

А так?
ВЫБРАТЬ
а,б, МАКСИМУМ(в) КАК в
ИЗ Регистр.Бюджет.Обороты КАК Бюджет
СГРУППИРОВАТЬ ПО
Бюджет.а,Бюджет.б

Вот что значит криво спроектированный регистр....

(8) не подходит, увы, все попадает
(9) ну может быть, может быть, ну а как иначе?

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

(10) как это "все пропадает" ???
в (8) отборов никаких нет, только по каждой паре а,б выбирается максимум (в)...

(12) попадает, а не пропадает)
(11) пробую....

(11) не учи плохому)

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

(14) намекаете, вернее прямо говорите, что надо ресурсом сделать номер корректировки?

(13) Так тебе нужно самое максимальное значение из всех пар?

(12), (14) Не решает задачу такой запрос. Как я понял, нужно получить значения А-Б-В при максимальном Ресурсе. В (11) правильно. Мне интересно, куда в (3) предлагается "ИМЕЮЩИЕ" затолкать.

(15) по сути да, из всех ни то, чтоб пар, разные комбинации организаций (а) и статей (б), но для одинакового сочетания надо выбрать с максимальным значением В

(15) нет, я просто не знаю, какой буквой ты обозначаешь ресурс. ну... который 100,150,300,400...

(18) если для  КАЖДОЙ пары максимальное значение - тогда (8) (14)

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

(10) >> ну а как иначе?

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

(18) если макисимальное значение(ОДНО!)  из всех пар:

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

(14) Ты не понял задачу автора. Перечитай внимательно (0)

(23) Ему МАКСИМУМ нужен не по ресурсу, а по ИЗМЕРЕНИЮ. Не тупи.

(22)* крайне рекомендует НЕ делать

(15) >> намекаете, вернее прямо говорите, что надо ресурсом сделать номер корректировки?

НЕТ!
И я такого не говорил.

(26) Только я бы к выборке присоединял бы левым РегистрНакопления.Бюджет КАК Бюджет

(28) Смысла в левом соединении нет никакого. Во-первых, мы делаем запрос к одной и той же таблице. А, во-вторых, это исказит результат - нам же нужно "отсечь" записи где измерение "в" НЕ максимальное.

(14) ругается,"Поле не найдено".

(24) ты хочешь сказать, что код в (14) не даст результата как в (0) ?

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

(31) Конечно нет. Ты путаешь измерение и ресурс.
Автору нужен МАКСИМУМ по измерению "в". А ресурс наоборот - НЕ должен суммироваться.

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

(29) Вера в великий оптимизатор?
Почему должно исказить результат?
И что что запрос к одной и той же таблице? Что кэш бесконечный?

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

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

   ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.Бюджет КАК Бюджет
        ПО Бюджет.А = ВложенныйЗапрос.А
            И Бюджет.Б = ВложенныйЗапрос.Б
            И Бюджет.В = ВложенныйЗапрос.В

Если человеческим языком формулировать, то ему нужны данные по последним (МАКСИМАЛЬНЫМ) корректировкам.

(35) При чем тут оптимизатор? В результате ЛЕВОГО соединения у тебя в итоге останутся ВСЕ записи из регистра. А автору надо ОТСЕЧЬ те, где номер корректировки (измерение "В") не максимальный. Отсечение реализуется внутренним соединением, а не левым.

+ к (35) inner join сиквел всяко быстрее отработает чем left join. Если регистр конский (миллионы записей), то лучше сделать выборку нужного во времянку с отборами, чем женить физику миллионную.

Ох, завтра на свежую голову опробую (11), т.е. внутреннее соединение. Ребят, всем большое спасибо за потраченное время, завтра подниму ветку с вашего позволения)

(38) Ну как бы соединение по индексу, если миллионные записи делать времянку на лямоны??? И чем inner join быстрее left join?

Если уж говорить об оптимизации, то может иметь смысл такая форма этого же запроса:

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

(41) Это что-то свеженькое :) наверное недавно завезли...

(42) Что именно?... Не понял.

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

Когда сиквел умножает таблицы, то при inner он может умножить как левую на правую, так и наоборот. При левом соединении такого пространства для оптимизации нет. В итоге, если быть точнее, inner работает точно не медленнее left join. Но, тут больше надо смотреть на условие. По условию, в выборке не должно быть записи {а1,б1,0 100}, а при левом соединении она будет. Таки в (11) правильно, только я бы сделал бы в виде пакетного, а не вложенного запроса.

(44) С чего вдруг {а1,б1,0 100} при внутреннем не должно быть?

(45) Да не будет, но и при левом тоже не будет

(43) :) Не знакома видимо такая конструкция. Но правда, я так не пишу. Внутреннее соединение мне понятнее.
(46) Левое ухо тоже можно почесать правой ногой, только обычно так не делают.

(47) С точки зрения оптимизации, то этот запрос может уйти в таймаут. Подумай про (11) как будет выполняться запрос, а как будет выполняться запрос из (35) и какой из них будет быстрее

(48) С хр... Почему это запрос должен в таймаут уйти? Я голосую за inner join, но мне не нравится ни 35 ни тем более 11. Мой вариант пакетом:
1. Выборка из физики в ВТ_ЧерновыеДанные. Актуально если большая таблица с данными. Можно индексировать, но надо измерять.
2. Получение максимума Ресурса с группировкой по а и б из ВТ_ЧерновыеДанные. Складываем в ВТ_ВложенныйЗапрос.
3. Выборка из ВТ_ЧерновыеДанные с внутренним соединением ВТ_ВложенныйЗапрос по а, б и Ресурсу.

Если физика маленькая и прогноза по её росту нет, можно работать с регистром и времянку в п.1 не создавать.

(49) * но мне не нравится ни 11 ни тем более 35.

(50) (Бюджет.А, Бюджет.Б, Бюджет.В) В и во что же будет преобразовано это чудо в ANSI-SQL?

(49) ядская дичь

индекс не работает при соединении 2-х больших таблиц, пора бы это знать, забудьте про него.

Йожик превед.
Так малоли...

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

Вы тут даже код банчите ?

Мне никогда не нравились измерения с типом число

(53) пруф или не было

(58) Он говорит что вероятнее всего оптимизатором будет выбран full scan, так как поиск в индексе может гораздо больше стоить.

(58) Давайте вы пораскинете мозгом, подумаете, как бы вы на месте разработчика БД соединяли 2 таблицы, и, вернувшись сюда, подтвердите мои слова.

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

(61) какой странный набор слов.

(62) Я не разговаривал с профайлером, хотя он очень просил.

(63) постарайтесь научиться понимать его мотивацию.

(64) Достаточно научился :-) Правда T-SQL уже подзабыл. Слоник лучше.

(65) До T-SQL 1С особо и не опускается

Ребят, доброе утро! Так с чего в итоге мне попробовать?) (11)?

Вроде бы (11) взлетело! Посмотрю на большЕм объеме данных. Миллионных записей не предвидится.

Спасибо всем за активную дискуссию, приятно, что вопрос не остался не замеченным. Отдельное спасибо автору (11).