Есть оборотный регистр НачислениеБонусов.
В нем измерение ДокументОплаты.
Документов оплаты может быть два типа.
Для каждого типа документов, есть свой динамический список, где через левое соединение берется значение с ресурса регистра НачислениеБонусов.

Как сделать оптимальней, с точки зрения производительности ? :
1. ДокументОплаты составной тип и по нем индекс.
2. Добавить еще одно измерение и будет ДокументОплатыТип1, ДокументОплатыТип2
Вероятность того, что в будущем добавится еще один тип документа оплаты очень маленькая.

Проведи эксперимент

(0) Оставь составной.

Сделай один динамический список, а в запросе сделай ОБЪЕДИНИТЬ ВСЕ

Я тоже за составной. Просто в соединении приводи тип через ВЫРАЗИТЬ.

А вообще, измерение типа "Документ" - моветон

Однозначно составной. Делать реквизиты наподобие ДокументОплатыТип1, ДокументОплатыТип2 - это кощунство )

(4) Зачем? У него и так сравниваются типы значений при соединении.

(0) А не является ли документ оплаты самим регистратором?

(5) А как иначе? Есть журнал документов, в нем должна быть колонка с суммой из регистра.

(8) нет. А если бы являлся, то чтобы это меняло?

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

Будь мужиком! Напили своих регистров! НачислениеБонусовПоДокументуОплатыТипа1, НачислениеБонусовПоДокументуОплатыТипа2,... НачислениеБонусовПоДокументуОплатыТипаN

(10) Тогда бы это измерение было не нужно

(9) >>  Есть журнал документов, в нем должна быть колонка с суммой из регистра.

Это кто сказал?... Кто-то при думал эту ересь, а вы её реализуете. Тут явно либо косяк в методологии, либо косяк в её применении на практике (через *опу).

(13) А в чем косяк? Ну хотят люди видеть сколько бонусов начислено каждым документом оплаты.

(14) Тогда это реквизит документа. Это не задача регистра и динамического списка.

(0) вообще не нужно соединений в запросе самого списка, используйте https://wonderland.v8.1c.ru/blog/obrabotka-i-oformlenie-dannykh-dinamicheskogo-spiska/

(15) Ну такое...
А если сделают возврат ДС? Бонусы оставляем?

(12) соединять по регистратору? записи задвоятся если движений более одного

В регистре Бонусы могут быть измерения Сотрудник, Сделка.
А может это вообще регистр расчёта?

(19) Оборотный?

(19) Моргни два раза, если тебя похитили фузиновцы.

(20) Если бонусы не списываются, а только начисляются, то оборотный, но это вряд ли. Скорее всего эти бонусы используются где-то ещё, например, при расчёте зарплаты.

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

Для вывода в несколько динамических списков, в том числе и по заказу покупателя (там еще одно измерение есть). И для одного отчета.
Возврат есть, по этому регистру минусует.

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

Я по итогу тоже не понял, нафига это измерение нужно и почему оплаты не двигают регистр.

Хотя регистр начислений оплаты и не должны двигать, чего это я...

(25) да это я тормознул в коментарии. В любом случае документ в измерении не является регистратором.

(23) У тебя просто сравнения строк в таблице. Ты же не производишь разыменования, не обращаешься к реквизитам составной ссылки.

(29) Ну так а приведение типа должно добавить еще условие на тип. Я бы подстраховался. Гуиды такие гуиды...

(28) Ну и какая логика движений по измерению "ДокументОплаты" в регистре начислений?

(14) (17) >> А в чем косяк? Ну хотят люди видеть сколько бонусов начислено каждым документом оплаты.
>> Ну такое...

"Ну такое" - это использовать вместо отчета динамические списки.
Хочется видеть какие-то свойства объекта - используй для этого типовые инструменты. Добавь свой допреквизит и либо регламент, который будет актуализировать значение этого допреквизита, либо подписку на события оборотного регистра, чтобы она актуализировала допреквизиты и свойства документа оплаты. Тогда для вывода реквизита в списках вообше ничего не надо будет делать - динамические списки и так допускают вывод допреквизитов.

Если автор не врёт в (24) про "Для вывода в несколько динамических списков", то решение с оборотным регистром - это пример методического кретинизма. Не предназначены для этого регистры накопления. По мере роста объёма данных работа таких динамических списков встанет колом. Собственно говоря, именно это сейчас и происходит (если я правильно понял).

(32) Ты прям драматизируешь. Ну хочет человек так сделать, пусть делает. Левое соединение с виртуальной таблице конечно зло, но к этому потом человек придет.