Иногда в конфигурациях используется независимый непериодический регистр сведений в тех случаях, где можно использовать справочник. Вот хочу задать методологический вопрос - какие это даёт преимущества (и даёт ли?)

Записи из регистра проще удалять. Пометок на удаление не надо. На регистр нет ссылок в других объектах.

ну приехали

примеры?

(0) На запись в регистре нет ссылки. То есть невозможно использовать в качестве реквизита. В отличии от... Зато можно не беспокоясь о ссылочной целостности еЯ удалять.

(3) Типовых примеров не знаю. Видел, например, блок по договорам был сделан на регистрах сведений, с кучей измерений и ресурсов.

(5) Блок по договорам - это слова.
Конкретно, что там было*

(5) нет примеров - нет объяснения

(6) Одна запись - один договор. Если кратко.

(8) Это еще, что было бы вообще удивительно, если бы была одна запись на 2 договора.

(8) И где такое решение применено? Чтобы не вляпаться...

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

(11) Не основным, а ведущим. Проверять не требуется, потому что это фича ещё со времён 8.0

(8) а как у реализации определялось по какому договору она отражается?

(0) Преимущество регистра перед справочником в том, что можно "грохнуть" запись без пометки на удаление.

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

(14) Угу, причем случайно, и причем неслучано - все.

(13) Вообще, стандартный справочник договоров, подчиненный контрагентам, остался. Он же выступает одним из измерений для записи регистра. Просто по блоку договоров много доработок. Ну и почему-то сделали для этого отдельный регистр сведений, вместо доработки справочника.

(17) Дык это же замечательно - 1С не изгадит при очередном обновлении.

(11), (12) Занятная фича...)

(18) Хотел написать - вместо создания отдельного справочника для договорной работы.

(17) так это совсем другое дело, это удобно и я рекомендую

(10) Далеко от Питера, не волнуйся)

(18) +разделение прав, +не дергаешь объект

(20) А зачем? Чтобы поиметь проблемы с их синхронизацией?

(24) Нет, я имел в виду, что стандартный справочник договоров остается, а для договорной работы использовать дополнительный справочник (а в данном случае использован регистр сведений).

(25) а почему не использовали дополнительные (общие) свойства?

(25) Ну и как их связывать?

Логично для хранения самих договоров использовать справочник, а для сопутствующей информации(доп условия и т.д.) - регистр сведений(тем более, если она(информация) может меняться).
Недостатка 2 - регистр, зараза, имеет свойство очень быстро разрастаться и скорость работы падает.
Второй недостаток - достаточно одному программеру написать НаборЗаписей.Записать() без отбора - и "усё пропало, шеу"...

(28) На этот случай можно поставить проверку в модуле набора записей, и не давать записать пустой набор, если только не Загрузка = Истина.

Основное преимущество регистра - составной индекс по измерениям

(14) Не ну а что сказать что то банальное типа справочник - ссылочный тип данных, а регистр нет? :)

(0) Есть еще такой аргумент: нужна ссылка - справочник. Не нужна - регистр сведений.

(0) Регистр сведений нужен там, где нужен составной primary key.