Надо хранить периодическую информацию об объекте, порядка 20 характеристик разного типа - ссылка на справочники, число, дата.
Что я сделал
Периодический регистр сведений с периодичностью по позиции регистратора, и режимом записи "подчинение регистратору."

Измерения
- Объект - ссылка на спраочник,
- Характеристика - Ссылка на План видов характеристик

Ресурсы
- Значение - ссылка на значение характеристики.

После 1000 записей начинаются тормоза при добавлении новых.
Поставил индексировать оба измерения.
Из-за чего тормоза? Получается внутри какой-то индекс большой (в ПВХ около 20 элементов)? Как оптимальнее решить задачу? Может использовать непериодический регистр сведений и эмулировать периодический на обычном регистре сведений?

Убери индексы при добавлении будет легче

вроде все правильно сделал

с индексами чтение будет быстрее, без индексов запись... я-бы индексы оставил...

возможно RLS есть? или блокировки?

(2) там же вроде как составные по умолчанию есть, может хватит?

Нет, никаких RLS нет, блокировок пока не навешивал управляемых.
Пока просто тестирую обычный чистый регистр.

база файловая ?

(0) сильно задумайся над этим ...порядка 20 характеристик разного типа :)

(6) На это и грешу. Как сделать лучше, т е в регистр накидать 20 ресурсов разного типа как-то не то, но с точки зрения нормализации правильно.

Да если периодичность уберешь будет легче

Вся суть в том что периодичность нужна, а так все как в УТ характеристики номенклатуры.

(6),(7) а как запись в РС уже записанной характеристики, может давать большую нагрузку нежели запись ссылки на любой другой объект?

Может с периодичностью секунда будет легче, но тогда будет проблема нескольких регистраторов с одним временем.

хотя межет ... проверка на уникальность

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

(7) ПВХ для того и сделан, что-бы составные типы приводить к нормализованому индексу, единственный минус - это дополнительный подзапрос, чем больше типов тем более эффективно использование ПФХ в индексах

Все нормально летает. Это я обложался.
был такой код
набор записей создавался 1 раз вне цикла
         НЗ = РегистрыСведений.ЗначенияХарактеристикПайщиков.СоздатьНаборЗаписей();

Пока ВЗ.Следующий() Цикл

         НЗ.Отбор.Регистратор.Установить(ВЗ.Регистратор);
         
         Выборка = ВЗ.Выбрать();
         Пока Выборка.Следующий() Цикл
              Запись = НЗ.Добавить();
              ЗаполнитьЗначенияСвойств(Запись, Выборка);
              Запись.Период = ВЗ.Регистратор.Дата;
         КонецЦикла;    
         
         НЗ.Записать();
    КонецЦикла;    


оказалось что он аккумулировал записи, т е писал по нарастанию вкаждый раз в регистратор все больше и больше

Пока ВЗ.Следующий() Цикл
         НЗ = РегистрыСведений.ЗначенияХарактеристикПайщиков.СоздатьНаборЗаписей();
         НЗ.Отбор.Регистратор.Установить(ВЗ.Регистратор);
         
         Выборка = ВЗ.Выбрать();
         Пока Выборка.Следующий() Цикл
              Запись = НЗ.Добавить();
              ЗаполнитьЗначенияСвойств(Запись, Выборка);
              Запись.Период = ВЗ.Регистратор.Дата;
         КонецЦикла;    
         
         НЗ.Записать();
    КонецЦикла;    

Надо либо создавать внутри, либо чистить после записи набор записей.

скорее всего что то с блокировками зря на регистр думаешь

у меня за 1-2 часа 4 миллиарда записей в рег сведений засунулось
после этого файловая система базу отказалась переваривать ;))
перешел на sql

Вообщем, проблема была в некорректных данных, точнее в способе их записи.

возьми sql profiler посмотри запросы

(17) У меня когда 6 000 000 записей регистр с логом изменений пошёл реструкторизироваться... я перешёл на MYSQL