Всем привет!

Подскажите как сохранить таблицу с вложенными данными в регистре сведений?

Есть данные с АТС, вида кто звонил и порядком обзвона (схема ниже):
|ID|КтоЗвонил|ПрядокОбзвона|ВходящийНомер|

Столбец "ПорядокОбзвона" имеет вложенную структуру
-Пользователь|ВремяЗвонка|
-Пользователь|ВремяЗвонка|

|ID|КтоЗвонил|ПрядокОбзвонаПользователь|ПрядокОбзвонаВремяЗвонка|ВходящийНомер|

Будет же задвоение строк. А вложенной таблицей это реально сделать? На подобии реляционной БД?

1)|ID|КтоЗвонил|ВходящийНомер|
2)|ID|LineNom|Пользователь|ВремяЗвонка|

(2) В реляционных бд нет вложенных таблиц...

(2) ну задвоение и задвоение. Какие проблемы? У вас тысячи звонков в день что ли? Что вы на какие-то вложенные таблицы заморачиваетесь?

(2) если не в 1с запихни в джисон

Можно же в регистре иметь структуру измерение день,а ресурс хранилище значения,где вся эта таблица сериализованная.

(0) Запихни в два регистра

(7) Убить за такое мало.

(9) Зависит от сценариев использования. Ты вот, например, в регистры адресного классификатора БСПшного давно заглядыывал?

(10) Даже если я туда заглядывал - это не повод не убивать за такое решение

(9) чего не так?
Это журнал,его будут смотреть или анализировать.
Если по нему нужно делать поиск,то уже отдельный регистр,где будут не текстовые строки,а ссылки.

И,например,все полученные документы ЕГАИС в типовых так хранятся,и никто не умер.
P.S.поля BLOB для такого и придумали,но одинэсники-то могут и не знать,что такое BLOB и шипеть как ядовитая змея.

(12) это динозавры которые помнят как блобы в 7. 7 хранились и поэтому шипят от воспоминаний

(12) "и никто не умер."
Потому что не убивали )))
Потому что такие, как вы, всё в блобы и в носкуль пытаетесь залить там, где это не надо.

(12) Болбы придумали несколько ))) для другого.

(14) > там, где это не надо
Как авторитетно-то прозвучало, а?

(16) Учись ))

BLOBы тут не причем. Хотелось сделать красиво и не плодить связные таблицы. Но уже все решилось по другому: В регистр пишутся raw данные, и разбор производится уже функциями и выводится на форму и/или далее по запросу.

(18) Ага, а теперь наполни регистр данными за год и сформируй отчет.
Суть реляционных БД - связные таблички.
Ох кому то повезет это потом разгребать

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

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

(21)журнал - не олап и  не олтп. отдельный вспомогательный  бизнес-процесс.
хранение  его данных в базе олтп - повод для увольнения (или кастрации) , тк нарушает правило быстрого восстановления из резервной копии.
и как следствие - может быть обнаружено админом дб из-за избыточных индексов

(20) ну надо тебе вложенные таблицы - ну подними ты эластик, там далее далее далее.
И он заточен под это.
А хранение в реляционной БД бинарей, которые распаковываются и постобрабатываются - повод усомниться в компетенциях.
Нет, есть конечно случаи, когда это необходимо, но это не этот случай.

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

(24) процесс вспомогательный, около-стоящий .по сравнению с основными бизнес-процессами -- не значащий. но конечно, если раздуть его значимость....
говно-админов не меньше чем говно-разработчиков. те
это чисто административный вопрос . впрочем как и скорость восстановления оперативной базы.

(23) от нормализации до  эласлтика - лет 20 опыта. но оно и про нормализацию не в курсе.

(2): нет, не будет. будут храниться все кортежи. которые легко получать и обрабатывать (кстати - вопрос "зачем?" - всегда актуален и первичен; в данном случае - данные именно затем).