Вход | Регистрация
 
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): нет, не будет. будут храниться все кортежи. которые легко получать и обрабатывать (кстати - вопрос "зачем?" - всегда актуален и первичен; в данном случае - данные именно затем).


Список тем форума
Рекламное место пустует  Рекламное место пустует
Проблемы невозможно решaть нa том же уровне компетентности, нa котором они возникaют. Альберт Эйнштейн
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.