Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 конвертатор большого xml  [new]
Виктор_777
Member

Откуда:
Сообщений: 24
Доброго времени суток! Я столкнулся с проблемой импорта xml файла (20Гб) в SQL. Используя процедуру
SELECT * from openrowset (bulk 'C:\1.xml', single_blob) as x 
не получается передать ее содержимое в обработчик
...
insert @T1 (PASPORT, SERIYA, NOMER, id)
select documentTypeName, documentSerial, documentNumber, id  from openxml(x, '/Export/Event/Client/document', 2)
with (
documentTypeName	nchar(50) ,
documentSerial	nchar(50) ,
documentNumber	nchar(50),
id int '@mp:parentid');


Подскажите пожалуйста как из переменной x вытащить нужные данные?
12 янв 14, 17:59    [15404915]     Ответить | Цитировать Сообщить модератору
 Re: конвертатор большого xml  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
При таком размере файла - никак.
12 янв 14, 18:38    [15405059]     Ответить | Цитировать Сообщить модератору
 Re: конвертатор большого xml  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31435
Виктор_777
Я столкнулся с проблемой импорта xml файла (20Гб) в SQL. Используя процедуру
SELECT * from openrowset (bulk 'C:\1.xml', single_blob) as x 
Думаю, даже openrowset не сработает, поскольку не сможет импортить более 4 гб как single_blob

Для файлов таких размеров нужно использовать XML Bulk.
12 янв 14, 20:25    [15405358]     Ответить | Цитировать Сообщить модератору
 Re: конвертатор большого xml  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
alexeyvg
Для файлов таких размеров нужно использовать XML Bulk.
Меня другое смущает, почему и для средних файлов надо ипаться через openrowset + openxml и эти росписи колонок, связки таблиц и оверхед с закачкой в доп таблу?
Это всё уйня и bad practices.

Блин, уже всё готово и процедура и процесс: 12410359
И главное в итоге одна команда и хоть 100500 таблиц надо закачать сразу и всё оптимальнейше.
13 янв 14, 07:20    [15406053]     Ответить | Цитировать Сообщить модератору
 Re: конвертатор большого xml  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31435
Mnior
alexeyvg
Для файлов таких размеров нужно использовать XML Bulk.
Меня другое смущает, почему и для средних файлов надо ипаться через openrowset + openxml и эти росписи колонок, связки таблиц и оверхед с закачкой в доп таблу?
Это всё уйня и bad practices.
Ну, если нужно вытащить несколько строчек из файлика, то удобнее, что бы всё было в небольшом блоке на T-SQL, без всяких там xsd файлов (которые нужно ещё куда то положить), так что сам по себе подход вполне востребованный.

А для полноценного импорта конечно вы правы.
13 янв 14, 09:25    [15406309]     Ответить | Цитировать Сообщить модератору
 Re: конвертатор большого xml  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
alexeyvg
без всяких там xsd файлов (которые нужно ещё куда то положить)
Эээ, а разве сам XML не надо куда-то положить если он читается с диска?
Я понимаю если XML приходит как параметр запроса.
И я понимаю если XML для тестов, временный и т.п.
Но когда это налаженный процесс, то не вижу аргументов против XmlBulkLoad.
13 янв 14, 14:53    [15408344]     Ответить | Цитировать Сообщить модератору
 Re: конвертатор большого xml  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31435
Mnior
alexeyvg
без всяких там xsd файлов (которые нужно ещё куда то положить)
Эээ, а разве сам XML не надо куда-то положить если он читается с диска?
XML файл будет куда надо класть клиент, у которого будет работать этот код - это ведь его данные для импорта, тут не придерёшся.

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

И оно вам надо?
13 янв 14, 15:20    [15408526]     Ответить | Цитировать Сообщить модератору
 Re: конвертатор большого xml  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
alexeyvg,

Может я сильно зациклился на своих решениях?

Обычно куда будет класться сам XML, как он будет туда класться и как он будет загружатся и куда - это всё продумывает разработчик. Соответственно эта вся инфраструктура (и как она разворачивается) на его плечах.
Чтобы были нужные каталоги, нужные конвертеры файлов, нужные тулзы и скрипты по доставке и обработке.
И как это всё логируется и контролируется.

Какими значениями будет это настраиватся - да, это уже проблемы клиента, но остальное на плечах разраба.

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

Более того, openrowset (и др. булки) без динамики путь к файлу не поменять, даже моя процедура так не ограничивает.

А файлы класть это не доверишь внешним клиентам, они должны пройти демилитаризованную зону.

Согласен. Моя процедура это моё личное решение, можно написать так что XSD указывается не через файл (путь к файлу), а передаётся напрямую. Нужно поменять её соответсвующим образом.

Вы считаете что это стоит сделать? Спрашиваю не только alexeyvg.
13 янв 14, 18:19    [15409828]     Ответить | Цитировать Сообщить модератору
 Re: конвертатор большого xml  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31435
Mnior
Не понимаю почему вы проводите линию ответсвенности только на уровне скриптов скуля, и так должно быть как стандарт.
Не, я не провожу "линию ответсвенности только на уровне скриптов скуля" специально. Я могу решить какую то задачу, например, написав cmd-файл.

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

То есть я делаю что либо не потому, что так "кошерно", а потому, что конкретно это решение принесёт мне, бизнесу, ещё кому то какой то бенефит.

Если для решения задачи можно использовать 2 программных объекта - процедуру и xsd файл, или 1 объект - процедуру, то я прикину, сколько я получу за использование одного лишнего объекта.

Если достаточно много, то почему не использовать?
Например, основной импорт (основной ETL, работающий на нашу DWH) делается на xsd схемах, потому что он должен быть производительный, там много данных.
Ещё один импорт (метаданные для данных, импортированных в ETL) не такой производительный, но там файлы мо 5-10-20 гб, там тоже не обойтись без XML-балка.
Но есть много импортов, несколько десятков, которые написаны по другому, и просто не хочется прлодить лишние сущности, ими управлять, деплоить и т.д.
13 янв 14, 19:48    [15410165]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить