pbdaЧто будет быстрее при прочих равных - разобрать xml по таблицам прям внутри базы хранимками или возложить это на .NET/CLR?Быстрее всего - XML Bulk Load (SQLXML); то же самое можно сделать на .NET
"прям внутри базы хранимками" - непонятно, что конкретно имеется в виду, но любой вариант будет медленее вышеописанных.

pbda>"прям внутри базы хранимками" - непонятно, что конкретно имеется в виду, но любой вариант будет медленее вышеописанных.
Императивный разбор, DOM + XPathДа, это, конечено, будет медленнее, чем Bulk

Yuri Abeleмноголетний опыт в BI с каждым годом всё больше убеждает, что чем сложнее исходные данные, тем менее рекомендуется решать все скриптами.Я всегда считал ровно наоборот - для простых данных хорошо подходят графические инструменты, для сложных альтернативы коду (скриптам) нет.
Правда, у меня опыт с графическеими инструментами ETL ограничен только SSIS (DTS), возможно, другие инструменты дают больше возможности разработчикам.

Yuri Abelealexeyvg... Я всегда считал ровно наоборот - для простых данных хорошо подходят графические инструменты, для сложных альтернативы коду (скриптам) нет.
Принципиально вот это: "Поддерживать и развивать такое убьётесь!"
Да, никто и не спорит, что скриптами можно написать гораздо более замороченную логику, но ... могу только еще раз себя любимого :-) процетировать: "Поддерживать и развивать такое убьётесь!"Да, я исключительно про "развивать и поддерживать", остальное не так критично.

- Микрософт не предоставляет разумного пути для работы над пакетом нескольких девелоперов.
- Не даёт возможности хранить пакет в сорс-контроле, с просмотром в человеческом виде сделанных изменений, и привязкой изменений к требованиям, проектам и т.д. (вот чтоб можно было сказать: "видим по истории, что 05.06.2019 Вася поменял тип выходной колонки ККК с decimal(13.2) на decimal(15.2), по запросу клиента №ННН")
- Не позволяет делать нормальные ветки, которые можно отдельно развивать и мерджить (например, Вася поменял импорт в таблицу А, через 2 дня Петя в таблицу Б, но задеплоить нужно будет изменения Пети, а потом через месяц смерджить изменения Васи с основным кодом)
- Не даёт возможности делать вменяемый поиск в пакете
- Пакеты плохо поддерживают модульность, обычно обработку для разных таблиц нужно делать (рисовать млышкой) по отдельности, в крайнем случае копи-паст и замена - но как это поддерживать? Если я нашёл ошибку, или внёс изменения по требованиям, я должен мышкой кликать на каждый из 200 остальных подобных квадратиков, и менять там руками? А как убедиться, что я поменял всё одинаково? И это "удобно поддерживать и развивать"?

Всё это критично даже не для замороченной логики, а просто для более менее объёмного ETL (то есть когда логика простая, но объектов много).

Мы когда то перешли в ETL с квадратиков, просто на такск типа Script, который при выполнении создаёт пакет и его выполняет :-) Хотя, согласитесь, это извращение. Но поддерживать стало более менее приемлемо.
Но потом окончательно отказались от SSIS, потому что его поддержка - это полный трэш.

Владислав Колосовразборщик-загрузчик на С++/С# с применением SMO.А как это, в чём идея?

Владислав КолосовSISS пакеты надо уметь готовить. Для тех, кто работал с ними поверхностно, невдомёк, что почти для каждого (!) параметра задачи можно использовать подстановочную переменную. При этом изменения вносятся в одном месте - в вычисляемое выражение переменной, все 200 объектов редактировать не потребуется для изменения, например, базового каталога выгрузки.А для изменений, например, маппинга полей источник-приёмник?
В DTS это всё было легко делать, но посре замены его на SSIS ситуация стала катастрофической, программируемость потеряна практически полностью.

Ну и сравнение версий с сорс-контроле не облегчается, при использовании "подстановочных переменных" :-)