Посмотрел видео собеседования https://youtu.be/_oY0YJ24E7Q?t=806, там на мой взгляд несложный вопрос, чем отличается хранения данных в табличной части справочника и регистра сведений в случаи если данных нужно хранить по конкретному элементу справочника. Ответ очевиден в ключе данных, в ТЧ ключ будет всегда один Ссылка, в регистре можно задать свой ключ по средствам измерений.
Вопрос, почему контактную информацию в типовых решили хранить в табличной части, а не как раньше в регистре сведений? чем это обосновывается?

Была такая проблема при обмене УТ11 с Бух., в УТ КИ хранится в ТЧ, а в Бух. в регистре и вот в УТ был задублирован адрес в одном контрагенте (различались только представления)  соответственно, пришлось делать доп. проверку при загрузке в БУХ., есть уже запись с таким ключом в Наборе или нет, это раз и два это что мы ни как не знаем какая из них более правильная и остается записывать первую!

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

Чтобы работал RLS по контрагентам.

(2) RLS и на регистр можно установить, тут поддержка уникальности по мне более оправдана следуя заповедям теории баз данных

блокировки, размеры таблиц, да мало ли что еще

Передача контрагентов вместе с контактами между узлами РБД

(3) ага особенно в большой базе ...

(4) могу ошибаться, но вроде как блокировки можно устанавливать не только на весь регистр, но и на отдельные записи регистра. А по размеру таблицу, что в ТЧ одна физическая таблица, что в регистре, отличаются только кол-вом индексов

(7) может битва за целостность данных? При записи контрагента должна в той же транзакции записываться его контактная информация

(5) В РБД как раз по фигу: есть изменения (хоть в РС) - перенеслось.

общий ответ - 42

(8) Согласен это плюс хранения в ТЧ, но пока непонятно перевешивает ли он минус отсутствия уникальности

Где лучше хранить свое в дополнительных реквизитах или дополнительных сведениях?

(12) ответ в (10)
А так логика понятна: нужно редактировать независимо от объекта - выбираешь сведения

(12) в файле, который загружен в отдельно стоящую SQL-базу в BLOB-поле

(10) на счет блокировок, при записи элемента справочника заблокируются в ТЧ записи по ключу Ссылка, а в регистре при записи Набора заблокируются записи по установленному отбору поэтому из-за блокировок сомнительно что такое сделали.

(11) Почему "минус"? Возможно это главная причина (хотя непонятно что мешало расширить ключ в регистре)

А еще если сравнить размер транзакции при записи элемента справочника с кучей реквизитов и таб. частей и одной записью  в регистр. Например, нужно загрузить только контакты придется перезаписывать все элементы справочника при хранении в ТЧ

(17) Как правило объектов с контактной информацией не так много (на фоне возможностей современного железа и ПО).
Сейчас в современных типовых конфах уход от нормализации и минимизации объема данных: куча служебных регистров которые пишутся в фоне и т.п.

Копирование контрагента вместе с контактными данными.
Сериализация/десериализация

(19) Ну эт бред. 2 дубля будет что ли?
Мне тоже непонятно сиё.

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

(21) Могли бы хотя бы проверку на дубли ПриЗаписи встроить в модуле объекта, так сказать обойти проблему уникальности

в (0) ответ ни о чем да еще и неправильный. Самое существенное различие именно в правах доступа: при хранении в одном регистре, чтобы нормально разделить права придётся использовать RLS.
Если в ТЧ - хватит тупо прав на сам справочник.

Помимо прав доступа ещё можно 2 телефона указать например

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

(24) с помощью костылей в виде/типе можно было так же указать в регистре)

(26) а версионирование?
Плюсов больше получается

(27) да никто не спорит

Причины перехода на табличные части в справочниках были следующими:

1 — оптимизация быстродействия
2 — возможность корректного разграничения прав доступа
3 — более логически верная конструкция. Не было никакого обоснования для хранения подобной информации в общем регистре, кроме того, что почесалась левая нога архитектора, впервые взявшего за реализацию учёта контактной информации в ранних конфигурациях — проще говоря, такая реализация изначально была ошибкой.

(29) + действительно сериализация/десериализация и общие обработчики событий

(29) как раз оптимизация в минус ушла

(31) Действительно. Ведь так удобно было получать СрезПоследних по регистру КонтактнаяИнформация... Теперь вот как получить актуальные телефоны?

(32)А что регистр контактной инфы был периодическим?

(0) Как почему. Что бы функцию написать в БСП и объект передавать, а не запросом по всем объектам к которым адрес можно привязывать и с составными типами работать. Из-за БСП так сделали - отвязались от типа объекта путем отвязывания от типа данных, но при этом копипаст структуры в каждом объекте - бред. Тогда бы сделали типы данных новые, которые не хранятся сами по себе, но могут назначаться объектам,  но тогда бы это была объектная древовидная БД как КАШЕ :-)
В общем заигрались с БСП.

(33) Конечно.

(35) Где? В БП2/УТ10/УПП никогда не был периодическим

(36) Мир не ограничивается типовыми

Есть вариант с последними релизами брать данные из истории изменений обычного текстового реквизита?

(37) но тема вроде как раз про них

На партнерке есть короткий неинтересный ответ: Права доступа.

Допреквизиты тоже хранятся в т.ч. объекта.
Удобство в том,что ПолучитьОбъект и больше в базу не ногой.
Опять же,то,что не планируется изменять отдельно от изменения объекта нет смысла хранить отдельно.

С правами,как раз можно и регистр через РЛС разделить.

(40) Было в (2)

а кстати - да. с переходом на уф и ресурсоемкие перегоны данныз сервер-клиент - получить на клиента пакет информации, обработать и перезнать обратно при набобе - гораздо проще и экономнее при хранении в "статистически значимого" пакета данных, характеризующего сущность, одном объекте.

Там ещё параллельное использование.
Если все читают или пишут одну таблицу,то на ней могут быть столкновения,особенно,когда в нее пишется новая запись.

(0) отчасти ради производительности, отчасти ради библиотечности, отчасти ради тяги к костылям. Не все технические решения фирмы 1с проходят нормально, некоторые отличаются нелепостью. Например, в 2007 году мы писали:

Сообщить("Привет мир!);

в 2021 году пишем:

ОбщегоНазначенияКлиентСервер.СообщитьПользователю("Привет мир!");

(43) "характеризующего сущность, В одном объекте" - адрес не сущность объекта и может отсутствовать. Это же не ИНН организации РФ и не дата рождения ФизЛица и не ФИО. Типов адреса тоже может быть сколько угодно и в разных форматах.

Повторюсь - всё дело в БСП. Разработчики БСП не знают к каким объектам будет привязываться адрес, поэтому от регистра с измерением и составным типом (неизвестного состава) этого измерения отказались.
Хочешь использовать БСП в части адреса в том или ином объекте - копипасть структуру и используй. В качестве параметра функций передается сам объект (+ может тип адреса и т.д. всё что уже относится к самому БСП), а какого он типа без разницы. Поменялась структура адреса - сиди во всех объектах приводи к соответствию. :-)

Правильно такая задача решается путем ввода специального типа данных, который можно назначать реквизиту объекта, что бы не копипастить структуру. В ООП это класс. В КАШЕ это специальный тип данных, который сам по себе не хранится, а только с объектом. Так как ООП в 1С нет и не будет, скорее всего, то пришло время создавать свои типы данных с методами - почти классы, но не классы.

А то всё рюшечки рисуются и УФ. Тут по возможностям архитектуры, платформы и работы с SQL (хотя бы стандартный SELECT расширить до стандарта оконных функций + стандартные конструкции типа select t1.a1 as a1, (select top 1 t2.a from t2 as t2) as a2 from b as t1) и т.д.. В общем непочатый край нормальной работы, а не рюшечек.