Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

Сохранение таблицы с вложенными данными

Сохранение таблицы с вложенными данными
Я
   idleVF
 
24.10.20 - 01:20
Всем привет!

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

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

Столбец "ПорядокОбзвона" имеет вложенную структуру
-Пользователь|ВремяЗвонка|
-Пользователь|ВремяЗвонка|
   Cthulhu
 
1 - 24.10.20 - 01:59
|ID|КтоЗвонил|ПрядокОбзвонаПользователь|ПрядокОбзвонаВремяЗвонка|ВходящийНомер|
   idleVF
 
2 - 24.10.20 - 02:24
Будет же задвоение строк. А вложенной таблицей это реально сделать? На подобии реляционной БД?
   youalex
 
3 - 24.10.20 - 04:02
1)|ID|КтоЗвонил|ВходящийНомер|
2)|ID|LineNom|Пользователь|ВремяЗвонка|
   ДенисЧ
 
4 - 24.10.20 - 07:22
(2) В реляционных бд нет вложенных таблиц...
   hhhh
 
5 - 24.10.20 - 12:58
(2) ну задвоение и задвоение. Какие проблемы? У вас тысячи звонков в день что ли? Что вы на какие-то вложенные таблицы заморачиваетесь?
   Йохохо
 
6 - 24.10.20 - 13:04
(2) если не в 1с запихни в джисон
   ДедМорроз
 
7 - 24.10.20 - 13:33
Можно же в регистре иметь структуру измерение день,а ресурс хранилище значения,где вся эта таблица сериализованная.
   acht
 
8 - 24.10.20 - 13:37
(0) Запихни в два регистра
   ДенисЧ
 
9 - 24.10.20 - 13:46
(7) Убить за такое мало.
   acht
 
10 - 24.10.20 - 14:04
(9) Зависит от сценариев использования. Ты вот, например, в регистры адресного классификатора БСПшного давно заглядыывал?
   ДенисЧ
 
11 - 24.10.20 - 14:04
(10) Даже если я туда заглядывал - это не повод не убивать за такое решение
   ДедМорроз
 
12 - 24.10.20 - 17:19
(9) чего не так?
Это журнал,его будут смотреть или анализировать.
Если по нему нужно делать поиск,то уже отдельный регистр,где будут не текстовые строки,а ссылки.

И,например,все полученные документы ЕГАИС в типовых так хранятся,и никто не умер.
P.S.поля BLOB для такого и придумали,но одинэсники-то могут и не знать,что такое BLOB и шипеть как ядовитая змея.
   Aleksey
 
13 - 24.10.20 - 17:25
(12) это динозавры которые помнят как блобы в 7. 7 хранились и поэтому шипят от воспоминаний
   ДенисЧ
 
14 - 24.10.20 - 17:41
(12) "и никто не умер."
Потому что не убивали )))
Потому что такие, как вы, всё в блобы и в носкуль пытаетесь залить там, где это не надо.
   ДенисЧ
 
15 - 24.10.20 - 17:41
(12) Болбы придумали несколько ))) для другого.
   acht
 
16 - 24.10.20 - 17:43
(14) > там, где это не надо
Как авторитетно-то прозвучало, а?
   ДенисЧ
 
17 - 24.10.20 - 17:45
(16) Учись ))
   idleVF
 
18 - 24.10.20 - 22:16
BLOBы тут не причем. Хотелось сделать красиво и не плодить связные таблицы. Но уже все решилось по другому: В регистр пишутся raw данные, и разбор производится уже функциями и выводится на форму и/или далее по запросу.
   palsergeich
 
19 - 24.10.20 - 22:26
(18) Ага, а теперь наполни регистр данными за год и сформируй отчет.
Суть реляционных БД - связные таблички.
Ох кому то повезет это потом разгребать
   Сияющий в темноте
 
20 - 24.10.20 - 23:23
тут нужно понимать,что индексированное хранение позволяет найти нужную запись.
а вот получение отчета за год по всем записям,боюсь,что в случае хранения raw данных меньшую нагрузку на сервер создаст,чем в связанных таблицах,которые все равно все сканировать.
   Сияющий в темноте
 
21 - 24.10.20 - 23:42
на самом деле,тех,кто предлагает распарсить файл журнала,нужно кастрировать
они подкладывают мину замедленного действия,так как никто не обещает,что записи в журнале уникальны,всегда возможна ситуация,когда встретится повтор записи,и все распарствание либо ляжет с ошибкой либо потеряет одну из записей.
да,в данном случае,есть ID,который подразумевает уникальность,но есть ли уверенность,что это так,конечно,всегда есть уникальность типа номер строки файла или номер позиции в файле,но они ничем не лучше,чем хранение а BLOB.
   МихаилМ
 
22 - 25.10.20 - 00:13
(21)журнал - не олап и  не олтп. отдельный вспомогательный  бизнес-процесс.
хранение  его данных в базе олтп - повод для увольнения (или кастрации) , тк нарушает правило быстрого восстановления из резервной копии.
и как следствие - может быть обнаружено админом дб из-за избыточных индексов
   palsergeich
 
23 - 25.10.20 - 00:36
(20) ну надо тебе вложенные таблицы - ну подними ты эластик, там далее далее далее.
И он заточен под это.
А хранение в реляционной БД бинарей, которые распаковываются и постобрабатываются - повод усомниться в компетенциях.
Нет, есть конечно случаи, когда это необходимо, но это не этот случай.
   Сияющий в темноте
 
24 - 25.10.20 - 01:01
(22) а ничего,что если журнал отдельно,то после восмтановления резервной копии мы можем получить ситуацию,когда у нас данные в файлах не соответсвуют базе?
просто,потом такие хранители отдельно после восстановленоя бэкапа базы узнают о том,что надо было бэкап не только базы делать,но обычно уже поздно.
   МихаилМ
 
25 - 25.10.20 - 01:14
(24) процесс вспомогательный, около-стоящий .по сравнению с основными бизнес-процессами -- не значащий. но конечно, если раздуть его значимость....
говно-админов не меньше чем говно-разработчиков. те
это чисто административный вопрос . впрочем как и скорость восстановления оперативной базы.
   МихаилМ
 
26 - 25.10.20 - 01:16
(23) от нормализации до  эласлтика - лет 20 опыта. но оно и про нормализацию не в курсе.
   Cthulhu
 
27 - 25.10.20 - 02:15
(2): нет, не будет. будут храниться все кортежи. которые легко получать и обрабатывать (кстати - вопрос "зачем?" - всегда актуален и первичен; в данном случае - данные именно затем).


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.