Всем привет. Есть потребность хранить перечень различных данных в разрезе документа, в регистре сведений - в ресурсе с типом ХранилищеЗначения.
Это может быть несколько таблиц, или несколько структур, неважно. Важно два момента:
- Вложенная коллекция может быть объемной, например таблица в 50к строк, или больше
- Есть возможность эти коллекции разбивать

Вопрос - как лучше помещать эти данные?
Одним куском - например структура с 10-20 таблицами, каждая из которых может иметь различные объемы. Будет одна запись с измерением документ и такой структурой в хранилище.
Или по одной таблице - будет 10-20 записей с измерениями Документ, ИмяКоллекции и самой коллекцией в ресурсе.
Просьба по возможности аргументировать выбор. Заранее спасибо.

делить на минимально требуемые единицы. т.е. если нужна будет в каком-то бизнес процессе одна таблица - она должна храниться отдельно от других. Если же данные используются всегда целиком - то пусть будет один кусок.

1

2

однополяроность проще и понятнее, а всякие многомеры от лукавого.

(0) Однозначно

(6)+ Ибо как разные сеансы/процессы будут читать-писать то?

(7) А с чего вы решили, что разные сеансы и процессы будут работать с этой таблицей? Мы вообще не знаем, как будут использоваться данные из этого хранилища и будут ли вообще. Поэтому и нет смысла в этой голосовалке.

И да.
Т.к. РС оно прекрасно работает с много записей, то каждую отдельную строку каждой таблицы можно в свою запись сувать.
Добавить к "Документ, ИмяКоллекции" еще уникальный внутри коллекции Ключ записи/строки, а в ресурс засовывать структуру строки таблицы.

(8) Опыт. И всегда предполагаю худшее.

(10) А потом окажется, что ТС захочет оперативно работать с таблицами из этого хранилища, делать запросы по таблицам, получать итоги по ним. И тогда вся тема просто в топку со всеми советами))

С точки зрения последующих обращений - лучше конечно разбить. Но тут тоже надо смотреть - ИМХО, 50 ресурсов тоже не хорошо.

Хранилище значения делает сериализацию при записи,поэтому,один кусок будет быстрее,чем несколько.
И,самое простое,посмотреть на механизм Присоединенные файлы.
И тут сразу будет ответ - нсли файл один,то и храним как один.
Если файлов несколько,то и делить на части.

(10) +1
(11) не окажется

Я за порционность просто потому, что во мне живет уверенность - если есть возможность разбить большой кусок на более мелкие, лучше разбить. Опять таки по-табличное чтение может понадобится. Что будет быстрее - считать все одним куском, использовать только две таблички, или считать отдельно только то что требуется.

(13) За десериализацию кстати - заметил сегодня неожиданный для себя момент. Были переживания за ссылки - что произойдет если в таблице есть ссылка, а имя таблицы этой ссылки изменилось. Так вот прекрасно восстановилось) Т.е. помещаю ссылку на МойСправочник, переименовываю в Удалить_МойСправочник, читаю - ссылка осталась, ошибки при чтении нет.
А вот штатная десериализация из json ожидаемо упала.

(12) речь не за 50 ресурсов, ресурс один - таблица. Будет 50 записей, а не 50 ресурсов.

(9) да нет, это уже слишком, такая детализация не нужна

(13) Выполнил замеры на выходных, не быстрее.

По результату пяти тестов получена таблица замеров, выкинута в сводную таблицу. Выигрышные замеры выделены светло синим цветом.  Чтобы избавиться от холодного старта – перед запуском снимаемых замеров выполнено несколько запусков тестов каждого вида:
https://ibb.co/X4jV7Q1

Разница по среднему времени:
https://ibb.co/nL4rmRJ

Память рабочего процесса
Счетчик: \Процесс(rphost*)\Байт виртуальной памяти - Показывает объем виртуального адресного пространства (в байтах), которое в данный момент использует процесс.  
Замер собран за время исполнения теста, выгружен в файл с разделителями, и проанализирован в Excell.  
https://ibb.co/9wFRpM7
Если сопоставить время пиков с таблицей замеров, увидим что пики приходятся на единовременное чтение структуры таблиц в тестах 1, 2, 5. В тестах 3, 4 пиков нет по той причине что счетчики работали с шагом в две секунды, и скорее всего их не засекли. Окрестностей времени тестов 3, 4 в собранных данных нет.
Пики также наблюдаются для операций по-табличного чтения, однако они более плавные.
Пики некритичные в данном случае – в 40-80 мб, но и окружение – тестовое, а не реальный прод с большим набором данных. Здесь только можно обратить внимание на сам факт прыжков памяти при единовременном чтении.

Тот же график в разлиновке по тестам (Т- таблицы, С - структуры):
https://ibb.co/PcBrBX8

(13) И,самое простое,посмотреть на механизм Присоединенные файлы
- да, была такая мысль, пока в подвешенном состоянии. Штатная десериализация упадет при изменении структуры метаданных, а если пилить свое то быстродействие скорее всего снизится.
Плюс нюанс описанный в (15) - уже из-за этого не хочется уходить от хранилища.

к (18) забыл описание теста: Тест выполнялся на серверной базе. Проверялось: чтение, запись через набор, запись через менеджер записи. Для: перечня таблиц сохраняемых отдельно, перечня таблиц сохраняемых в структуре.
Исходно сгенерирована таблица размерностью 80 колонок на 10 тысяч строк и раскопирована на 10 копий. Т.е. есть структура с 10 такими таблицами сохраняемая одним куском, и есть 10 таблиц сохраняемых по-отдельности.