Форумчане заранее прошу прощения за повторный вопрос, возможно в прошлый раз не все были в сборе)
Нужно хранить много данных с табличной частью.
Вопрос хранить данные в справочнике с табличной частью или в 2-х регистрах сведений и связать их между собой искусственной ссылкой?
Кто как считает? Записей будет много миллионов - большие объемы данных.

уникальность записей регистра сведений тоже кстати не нужна

Вы одну и ту же базу купили вместе с Ограничение в табличной части документа 99 999 строк ?

(0) Подробнее

у меня не будет в табличной части больше 99999 строк, мне это не страшно

в конце прошлого года обсасывали

(0) >> хранить данные в справочнике с табличной частью или в 2-х регистрах сведений ...?

А почему нет варианта "в справочнике и регистре сведений"? Почему варианты только такие?

Слишком мало исходной информации, чтобы давать советы.
Правильный ответ напрямую зависит от задачи - что конкретно предполагается с этой информацией делать.
У каждого решения есть свои плюсы и минусы. Какие из плюсов и минусов станут критичными зависит от задачи.

(5) Видимо, не до кости :)))))))))))))))))))

(6) Поддерживаю. Слишком мало вводных.

в табличной части.

хотя можно наверно и универсальный ответ, если данных очень много, то всегда регистр конечно. но зачем два.. тема не раскрыта

(10) Ну как зачем - чтобы повторяющиеся данные шапки наверное не множить в строках регистра, задуманного под ТЧ

Нужно хранить историю - Уведомление и список сотрудников этого уведомления, поэтому Уведомление это одна табличка, список сотрудников - табличная часть этого уведомления. С данными что нужно делать - дописывать данные, писать запросы к этим данным.

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

(13) регистр нужно делать, нахрена тут справочник

почему регистр?

нужно понимание, более развернутое понимание

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

Уведомление - элемент справочника. Список получателей и сопутствующая информация (статус доставки, прочтения, даты и т.д.) - регистр с измерениями "уведомление + участник"

уведомление - это уведомление которое сработало и уведомило людей - туда пишется факт отработки действия и нужен список сотрудников этого уведомления

если это делать справочником, то тогда зачем регистр сведений, если в справочнике есть табличная часть

(20) Чтобы не перезаписывать объект целиком при изменении его ТЧ

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

в регистр можно дописывать или удалять наборы записей. В справочник нет. И да, можно строчки перезаписывать по одной, но если это будут строчки из ТЧ справочника, то перезаписываться каждый раз будет полностью объект со всей-всей ТЧ и шапкой.

Перезаписываться данные не будут, т.к. эти данные отражение просто факта истории, событий.

да и если надо перезаписать справочник - взяла элемент справочника да перезаписала, база не повиснет же из-за этого

(25) это смотря с какой интенсивностью все это будет выполнять пользователь. Если это база в одно лицо и тч объекта измерятся сотнями или тысячами записей - еще нормально.
Много-много пользователей, много-много записей. И будешь тогда уже думать, что писать лучше транзакциями по 100-200 строк, например... В результате выйдешь на "те же яйца вид в профиль"
Набор записей из одной ТЧ - это конечно здорово. Не всегда. Под энергосбытовые и другие жкх так не пойдет.

последнее сообщение не поняла

(22) интерактивное открытие объекта с большой табчастью приведет к его полному чтению и тормозам. Если строк действительно много, то лучше регистр. А ключ регистра - ссылка на справочник + номер строки (число).

(12)
справочник+подчиненный справочник
(6)+1

интерактивное открытие объекта с большой табчастью приведет к его полному чтению - как это понять и что такое не полное чтение объекта тогда. Кстати строк в табчасти не много - ну 200-300 строк

что за не полное чтение объекта?)

Таже товарищи из фузины знают что Ссылка.дата - приводит к чтению всех табличных частей объекта

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

(33) потому что подчиненный можно читать и писать по каждой записи без загрузки всего объекта, который будет грузится на клиента всегда весь, со всей ТЧ, если она будет у него задана.

(30) не знаю захочешь ли смотреть видео, а не читать текстом - там доклад с Инфостарта. Я его всем раздаю, потому что мне самому было интересно его посмотреть.
Там не впрямую отвечает на твой вопрос, но если уж появляется недоумение, что такое чтение объекта и как это может быть важно для оптимизации работы с клиентом, то вот видео посмотри, не игнорь :-)

https://youtu.be/PvQX0H28S_M

(33) "Уведомление + участник". А что подразумевается под уведомлением? Оно как объект уже есть в системе?

Есть какой-то списочный документ, например УвольнениеСотрудниковСписком - кадровые работники хотят уведомление на рабочий стол, на почту, смс - каждый сам себе настроит. В документе списки сотрудников с разными датами уведомлений, как подходит срок увольнения, то каждому кадровому сотруднику приходит уведомление например на почту что 4 сотрудника из документа скоро увольняются. Самим увольняющимся сотрудникам этого документа тоже приходят уведомления. Если уведомления кадровым работникам, то нужно зафиксировать уведомление и список увольняемых сотрудников попавших под это уведомление, т.е. каждый день потихоньку список сотрудников документа выгребаем.

Описалась --> В документе списки сотрудников с разными датами увольнений