Есть документ начисление за месяц, в нем к примеру 5000 строк начислений, но мне нужно еще иметь возможность каждое начисление детализовать до дня (и там параметров штук 10 из которых и расчитывается значение).

Теперь вопрос
В каком виде и где хранить эту самую детализацию?

вид - например это может быть хранилище в котором ТЗ, или например просто текстовое описание или структура...

жду вариантов

ps
если пытатся в лоб запихнуть это в основную ТЧ это будет 150 000 строк, как-то не очень мне нравиться...

Почему не Регистр сведений?

(1) по тому как эти данные первичные к данным в ТЧ документа

(0) Классически (в типовых) как правильно заметили в (1) это решается через Регистр Сведений
Где делаются два измерения Документ + ИдентификаторСтроки
А в ресурсы и реквизиты можно что угодно и как угодно писать
Хоть свою ТЗ сериализуй и засовывай внутрь ХранилищеЗначения

(3)+ ИдентификаторСтроки - это поле в ТЧ документа, куда пишется некий уникальный идентификатор (чаще всего банально Строка(Новый УникальныйИдентификатор)) для связи строки документа с записью(ями) РС

Если у тебя записи в РС должны быть раньше чем создание документа - придется как то выкручиваться
Через другие параметры-измерения, которые в документе так же есть
Например дата, вид начисления и прочее

(3) в типовых это лежит во второй ТЧ и связь по идентификатору

(6) да бывает и во второй ТЧ
а бывает в РС
судя по кол-ву записей лучше РС

прогнозно: будет примерно 100 таких документов в месяц,

то есть до 200 мл записей в год, может хранить в виде соответствия
ключ - дата
значение - текста типа "100*10/5-25*4=100"

дальше поместить в хранилище и в основную ТЧ ?

(8) Ты учти что ТЧ оно медленней чем РС
И еще одна ТЧ нагружает сам документ, работу с ним, его запись и проведение
Всегда если можно использовать РС - надо использовать РС!
ТЧ использовать только если преимущества явные, ну там мало записей и надо чтобы они были явно привязаны к документу, не были никогда отдельно от него.

(4) +1

да, за (1) +1, 120 млн в год не было, на порядок меньше, но за годы набралось ~120, работает, не как молния конечно, но приемлемо
а если вольнодумствовать, то корпоративные субд на большие объемы не рассчитаны. МайСиквел или ФриБСД гораздо успешнее справляются с такого рода задачами

(9) хранилище это блоб, оно по любому хранится физически в отдельной таблице.

Из минусов хранения в самом документе я вижу только скорость передачи контекста формы с клиента на сервер и обратно.

А вот хранить отдельно минус это возможность рассинхронизации.

По скорости работы - не знаю, но думаю, что блокировка 150 т записей в регистре и перезапись (а перезаписывать придется по отбору Документ все элементы на любой чих) думаю не сильно быстро выйдет

(12) ну да, еще если сразу лить, то и памяти может не хватить
гм.. куда 120 млн делись уже)

(13) 150 тыс это по 1 документу, то есть если я например в документе что-то перетасую, то мне нужно записать все 150 тыс вместе с запью документа

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

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

(0) > если пытатся в лоб запихнуть это в основную ТЧ это будет 150 000 строк, как-то не очень мне нравиться...

Почему? Если сделать в строке 31 колонку и писать туда данные.

> По скорости работы - не знаю, но думаю, что блокировка 150 т записей в регистре и перезапись (а перезаписывать придется по отбору Документ все элементы на любой чих) думаю не сильно быстро выйдет

Почему? Записи РС будут генериться только в момент создания.

Пользователь открыл документ, встал на определенную точку, прочитались записи связанные с конкретно этой строчкой. Что-то изменил переписались записи только для этой строчки.

Не надо РС, это лишнее. Раз документ или документы приходят раз в месяц, то излишне вести дневной регистр. Достаточно расчётным путём внешним отчётом каждый раз собирать дневные записи по каким угодно параметрам.
И работу не тормозит. Кому приспичит - запустит свой внешний отчёт.

А то дай вам волю, вы на каждый пук регистр создадите.

"Есть документ начисление за месяц, в нем к примеру 5000 строк начислений... это будет 150 000 строк"(0) - навеяло: «Может, в консерватории что-то подправить?»

Все 150 000 строк деталировки уникальны по значениям показателей? А если не уникальны - то может быть хранить только "типовые строки" и регистрировать только отклонения от них? Тогда алгоритм м.б. следующий: нет деталировки к начислению - см. "типовую строку"... как-то вот так.

PS: мало данных, чтобы давать реально полезные советы автору... но попробую предположить/предложить.

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

(20) это логичное решение, примерно так реализован зуп.

Кстати сейчас пришла интересна идея, может действительно использовать виды расчёта..

Тут основная хотелка получить простую систему с малым количеством этапов расчёта. Чтобы меньше ошибок было

(21) Пожалуй... мысль неплохая. Мне нравится. Сработает ли? Непонятно.

сделал так (работает вполне нормально)

в ТЧ добавил реквизит ХранилищеЗначений, в него кладу соответствие дата/структура все параметры в структуре имеют примитивный тип (сейчас 6 шт)
По сколько хранилище в ТЧ, то в реквизит формы не серелизуется   и при передаче контекста этого поля просто нет, а значит и на скорость не влияет.

Есть небольшая заморочка с использованием, но меня вполне устраивает