SQLRU.net
Разработка приложений баз данных

Начало » Использование СУБД » Firebird, HQbird, InterBase » UDR для разбора XML (Старый Новый Код)
UDR для разбора XML [сообщение #1333] Fri, 13 January 2023 23:43 Переход к следующему сообщению
shalamyansky в настоящее время не в онлайне  shalamyansky
Сообщений: 150
Зарегистрирован: August 2022
Senior Member
Продолжаем развлекаться:

https://github.com/shalamyansky/fb_xml

[Обновления: Sat, 14 January 2023 01:00]

Известить модератора

Re: UDR для разбора XML [сообщение #1348 является ответом на сообщение #1333] Mon, 16 January 2023 08:34 Переход к предыдущему сообщениюПереход к следующему сообщению
sg729 в настоящее время не в онлайне  sg729
Сообщений: 58
Зарегистрирован: June 2022
Member
С xml больших объемов работает? Например, если попробовать импорт файлов из "ГАР" (https://fias.nalog.ru/Updates), справится?
Re: UDR для разбора XML [сообщение #1353 является ответом на сообщение #1348] Mon, 16 January 2023 18:34 Переход к предыдущему сообщениюПереход к следующему сообщению
shalamyansky в настоящее время не в онлайне  shalamyansky
Сообщений: 150
Зарегистрирован: August 2022
Senior Member
sg729 писал(а) Mon, 16 January 2023 08:34
С xml больших объемов работает? Например, если попробовать импорт файлов из "ГАР" (https://fias.nalog.ru/Updates), справится?
Пуркуа бы и не па? Чтобы не быть голословным, пришлось скачать ваш ГАР ФИАС (35 Гб), ну да пригодится. Взял самый большой файл AS_HOUSES_PARAMS_20230112_83934110-95e8-43bb-86f8-8010766301 21.XML (400 Мб) - работает. Времена, конечно, макроскопические, но там же файл надо еще в память загрузить.

Кстати, для чтения файлов, из файловой системы или из zip, есть другой пакет

https://github.com/shalamyansky/fb_sys

Почему-то конкретно этот zip от ФИАС он не захотел открывать, но это я посмотрю, поправлю. А в плане XML все хорошо.

Re: UDR для разбора XML [сообщение #1356 является ответом на сообщение #1353] Tue, 17 January 2023 09:56 Переход к предыдущему сообщениюПереход к следующему сообщению
ggreggory в настоящее время не в онлайне  ggreggory
Сообщений: 76
Зарегистрирован: July 2022
Member
shalamyansky писал(а) Mon, 16 January 2023 18:34
Времена, конечно, макроскопические, но там же файл надо еще в память загрузить.
А можно по-конкретнее? Сколько время загрузки и простейшей обработки 400 Мб xml?

[Обновления: Tue, 17 January 2023 09:56]

Известить модератора

Re: UDR для разбора XML [сообщение #1357 является ответом на сообщение #1353] Tue, 17 January 2023 10:07 Переход к предыдущему сообщениюПереход к следующему сообщению
sg729 в настоящее время не в онлайне  sg729
Сообщений: 58
Зарегистрирован: June 2022
Member
Преогромное Спасибо!
Строго говоря, ГАР совсем не мой, а детище налоговой. Пробовал импорт в IBExpert - не хватило терпения ждать. Не знаю какой xml-парсер использует IBExpert : микрософта или омни, возможно проблема в парсере.
Вообще, сложилось ощущение, что сохранение записей базы данных в формат xml - сомнительное занятие. Если файл будет 1,5 - 2 Гб (как например по Москве), сможет ли парсер обработать его за приемлемое время? Ведь парсер, если не ошибаюсь, сначала грузит весь файл и только затем начинает расшифровывать его.
Re: UDR для разбора XML [сообщение #1363 является ответом на сообщение #1357] Tue, 17 January 2023 14:07 Переход к предыдущему сообщениюПереход к следующему сообщению
basid в настоящее время не в онлайне  basid
Сообщений: 162
Зарегистрирован: June 2022
Географическое положение: Asia/Irkutsk
Senior Member
sg729 писал(а) Tue, 17 January 2023 15:07
Ведь парсер, если не ошибаюсь, сначала грузит весь файл и только затем начинает расшифровывать его.
Зависит от XML-парсера.
Если "деревянный" (DOM) - в памяти строится представление документа и всё может быть плохо.
Если "потоковый" (SAX/StAX), то парсер разбирает и нормализует документ, формируя поток тегов, атрибутов и значений.
В этом случае разборщику не требуется много памяти, а проблемы приложения, которое фактически будет обрабатывать сформированный поток "шерифа не волнуют".
Re: UDR для разбора XML [сообщение #1364 является ответом на сообщение #1363] Tue, 17 January 2023 15:59 Переход к предыдущему сообщениюПереход к следующему сообщению
SD в настоящее время не в онлайне  SD
Сообщений: 411
Зарегистрирован: August 2022
Senior Member
XML предназначен для слабо- или вообще неструктурированных данных. На строгую реляционную структуру, где точно заданные сущности имеют точную структуру атрибутов он натягивается плохо.
Re: UDR для разбора XML [сообщение #1365 является ответом на сообщение #1357] Tue, 17 January 2023 18:22 Переход к предыдущему сообщениюПереход к следующему сообщению
shalamyansky в настоящее время не в онлайне  shalamyansky
Сообщений: 150
Зарегистрирован: August 2022
Senior Member
sg729 писал(а) Tue, 17 January 2023 10:07
Cложилось ощущение, что сохранение записей базы данных в формат xml - сомнительное занятие.
Согласен. Кроме того, скажу, что если вы решили с помощью данной библиотеки делать на сервере полный разбор больших XML, то это не лучшая идея, хотя теоретически вы можете. Каждый вызов nodes производит новый парсинг фрагмента XML (хорошо еще, если только фрагмента - зависит от вашего алгоритма) и заново строит DOM, поэтому при сложной структуре число вызовов и разборов увеличится многажды, соответственно и времена. Библиотека ориентирована не на полный разбор больших данных, а на извлечение некоторых значений из их xml-представлений.

Полный разбор и обработку первичных данных лучше делать на клиенте заточенными под это инструментами. Не царское серверное это дело - в сырых данных ковыряться.

Расскажу, как у нас это дело организовано, задачи похожие, судя по всему. В качестве входной информации выступают данные той же ФНС, а именно ЕГРЮЛ. Каждый обменный файл ЕГРЮЛ (их может быть несколько в день и свыше сотни в начале года) формата zip содержит в себе до 100 обменных XML, каждый из которых включает в себя до 1000 документов-выписок. Каждый документ имеет довольно сложную иерархическую структуру.

Программа-загрузчик (клиент Firebird) все это хозяйство разбирает и раскладывает по реляционным полочкам (до 200 таблиц). Любые выборки и анализы возвращаются потребителям (другим клиентам) уже из этих таблиц. Система (серверная часть), однако, оставляет возможность потребителю получить и сырые первичные данные. На всякий случай, а случаи, как известно, бывают разные. Эти сырые данные сервер добывает из первичных zip/xml, используя библиотеку fb_sys.udr (раньше использовал похожую udf).

Иногда при обнаружении ошибок разбора и загрузки или при подозрении на такие ошибки приходится залезать в первичные xml, вытаскивать некоторые значения и проверять/править рабочие данные. Вот для этого и понадобилcя модуль fb_xml, вот под такую работу он и спроектирован. Буду рад, если вам тоже пригодится.

[Обновления: Tue, 17 January 2023 18:31]

Известить модератора

Re: UDR для разбора XML [сообщение #1366 является ответом на сообщение #1356] Tue, 17 January 2023 18:28 Переход к предыдущему сообщениюПереход к следующему сообщению
shalamyansky в настоящее время не в онлайне  shalamyansky
Сообщений: 150
Зарегистрирован: August 2022
Senior Member
ggreggory писал(а) Tue, 17 January 2023 09:56
Сколько время загрузки и простейшей обработки 400 Мб xml?
От железа же зависит. На нашем старом сервере (Xeon 3500 32Гб) - минута с копейками. Но он плотно загружен основными задачами.

basid писал(а) Tue, 17 January 2023 14:07

sg729 писал(а) Tue, 17 January 2023 15:07
Ведь парсер, если не ошибаюсь, сначала грузит весь файл и только затем начинает расшифровывать его.
Зависит от XML-парсера.
Если "деревянный" (DOM) - в памяти строится представление документа и всё может быть плохо.
Именно DOM. OmniXMl - DOM, MSXML - тоже DOM. Памяти DOM может съесть больше, чем исходный XML, поэтому для XML размером под-за 1Гб, да еще на 32-разрядной ОС может и адресного пространства не хватить, не говоря уж о доступной куче. Разбирать "в лоб" такие файлы - не самая благодатная задача.

[Обновления: Tue, 17 January 2023 18:41]

Известить модератора

Re: UDR для разбора XML [сообщение #1367 является ответом на сообщение #1364] Tue, 17 January 2023 19:01 Переход к предыдущему сообщениюПереход к следующему сообщению
shalamyansky в настоящее время не в онлайне  shalamyansky
Сообщений: 150
Зарегистрирован: August 2022
Senior Member
SD писал(а) Tue, 17 January 2023 15:59
XML предназначен для слабо- или вообще неструктурированных данных.
Не могу с вами согласиться. XML предназначен для хорошо структурированных иерархических данных, то есть данных, включающих в себя отношения (неограниченной) вложенности. Реляционная же модель для подобных структур не предназначена никак. Их натягивают на конкретные наборы таблиц различными методами, каждый здесь присутствующий приведет с ходу несколько таких методов, но сама модель для иерархии не предназначена. Ни модель, ни операторы работы с ней.
Re: UDR для разбора XML [сообщение #1376 является ответом на сообщение #1367] Wed, 18 January 2023 20:41 Переход к предыдущему сообщениюПереход к следующему сообщению
sim_84 в настоящее время не в онлайне  sim_84
Сообщений: 330
Зарегистрирован: June 2022
Senior Member
На мой взгляд XML как формат передачи данных крайне неудачное решение. Хотя бы из за огромной избыточности. Опять же сложность представления специальных значений вроде null. Уж лучше json. О чем думали в налоговой когда решили ГАР в XML выкладывать фиг знает. Единственное в чем действительно хорош XML так это в сочетании с XLT для преобразования в различные представления. Но опять же эта штука хорошо работает на относительно небольших обьемах
Re: UDR для разбора XML [сообщение #1398 является ответом на сообщение #1376] Thu, 19 January 2023 21:54 Переход к предыдущему сообщениюПереход к следующему сообщению
Старый Плюшев в настоящее время не в онлайне  Старый Плюшев
Сообщений: 95
Зарегистрирован: August 2022
Географическое положение: Ленинград
Member
sim_84 писал(а) Wed, 18 January 2023 20:41
О чем думали в налоговой
Дальше можно было бы и не продолжать. Мишустин ушёл на повышение и вся цифрофикация по-моему не только застопорилась, а стала деградировать. Все попытки заплатить налог в этом году на их сайте заканчивались лапидарным "В данное время сервис недоступен". Заплатил через Госуслуги, собственнолапно внося сумму неизвестно за что. Однажды я уже платил два раза потому что квитанцию выставили не с тем номером счёта. Пришёл разбираться - так ты же не туда заплатил, сам виноват. Вернуть не можем, перенести не можем, постараемся зачесть в следующем году. Ну да, я же сам эту квитанцию слепил и номер из пальца высосал. Поэтому сейчас вспомнил что надо бы проверить, попал ли платёж куда надо. Зашёл. Вот эту фигню наблюдаю уже 23 минуты.
  • Вложение: FNS.jpg
    (Размер: 77.08KB, Загружено 940 раз)
Re: UDR для разбора XML [сообщение #1413 является ответом на сообщение #1333] Fri, 20 January 2023 16:24 Переход к предыдущему сообщениюПереход к следующему сообщению
shalamyansky в настоящее время не в онлайне  shalamyansky
Сообщений: 150
Зарегистрирован: August 2022
Senior Member
Вступлюсь немного за XML. Если данные не "плоские", то другой универсальной альтернативы как бы и нет. К стандарту XML прилагается стандарт XML-schema, метаданные, по сути стандарт документации, по которой можно корректно без потерь и даже автоматически организовать экспорт/импорт. JSON похож по организации, но к нему схем нет, чтобы организовать прием-передачу, надо либо смотреть примеры, либо изучать словесное описание, точнее, делать и то, и другое. А с XML схемой достаточно только схемы. Избыточность в смысле количества байтов нивелируется упаковкой XML в архивы, да и по сравнению с JSON эта избыточность не так уж велика.

А вот за ФНС и вообще гос. органы заступаться не буду. Лет 10 назад им спустили установку выкладывать открытые данные, они это сделали, но полное ощущение, что сделано это на "отъ..ись". Та же налоговая и файлы дает, и схемы дает, но формат файлов не соответствует схемам. Пишешь им про это, сперва дурочку изображают, отвечая на незаданный вопрос, а на заданный не отвечая, потом и вовсе высокомерно умолкая.

А вот мое любимое - пример именования ежемесячного обменного файла некоего другого гос. органа:
data-31082021-structure-20180329.zip
Числа в названии - это даты данных и версии структуры данных соответственно. Обратите внимание на форматы этих дат.
Re: UDR для разбора XML [сообщение #1426 является ответом на сообщение #1413] Sat, 21 January 2023 13:49 Переход к предыдущему сообщениюПереход к следующему сообщению
ggreggory в настоящее время не в онлайне  ggreggory
Сообщений: 76
Зарегистрирован: July 2022
Member
shalamyansky писал(а) Fri, 20 January 2023 16:24
Обратите внимание на форматы этих дат.
Ничего удивительного. У них же не один человек делает. У одного сотрудника одни предпочтения, у другого другие. Да и текучка кадров может влиять: работу уволившегося сотрудника с одними предпочтениями продолжает новый сотрудник с другими.
Re: UDR для разбора XML [сообщение #1432 является ответом на сообщение #1426] Sat, 21 January 2023 17:35 Переход к предыдущему сообщениюПереход к следующему сообщению
basid в настоящее время не в онлайне  basid
Сообщений: 162
Зарегистрирован: June 2022
Географическое положение: Asia/Irkutsk
Senior Member
А каким, простите, боком предпочтения сотрудника к крупицам рациональности?
Re: UDR для разбора XML [сообщение #1433 является ответом на сообщение #1333] Sat, 21 January 2023 23:26 Переход к предыдущему сообщениюПереход к следующему сообщению
МП в настоящее время не в онлайне  МП
Сообщений: 887
Зарегистрирован: August 2022
Географическое положение: бурятский тун...
Senior Member
Бардак невозможно автоматизировать.
Его можно только усугубить.
Re: UDR для разбора XML [сообщение #1435 является ответом на сообщение #1432] Sun, 22 January 2023 00:06 Переход к предыдущему сообщению
ggreggory в настоящее время не в онлайне  ggreggory
Сообщений: 76
Зарегистрирован: July 2022
Member
basid писал(а) Sat, 21 January 2023 17:35
А каким, простите, боком предпочтения сотрудника к крупицам рациональности?
Рациональность здесь непричем. Это особенности, возникающие внутри большого проекта со сложной организацией взаимодействия.
Предыдущая тема: FB3 как установить типом "приложение" и запустить?
Следующая тема: FB3 как правильно использовать embedded?
Переход к форуму:
  


Текущее время: Sat Nov 23 13:20:19 GMT+3 2024

Общее время, затраченное на создание страницы: 0.00883 секунд