Оказывается, вы развлекаетесь не только оркестрацией на SQL, но и трансформацией данных через ADO!
(записал вторым пунктом)

Это вы где-то прочитали или сами выдумали?
Вообще непонятно, что такое "прямая функция". Язык оптимизирован под трансформации? Но это совсем не про SQL.

Непонятная мне фраза. Что такое стандартные библиотеки (в отношении трансформаций) и почему их использование должно уравнивать скорость?

Пример: я складываю 1 млн строк через StringBuilder и через Concat. И то, и другое вроде бы стандартно-библиотечно, но скорости будут сильно отличаться...


Здесь более уместно смотрелось бы слово "вера".

В SSIS относительно легко и бесшовно (по сравнению с SQL Server) можно применять код на C#, и я активно пользуюсь этой возможностью. Подавляющее большинство трансформаций выполняется так гораздо быстрее и эффективнее, чем на SQL.

Дайте некоторое время побыть адвокатом дьявола и сотрясти воздух эпитетами о "кривом SSIS".

1. Я работал с проектами SSIS на различных версиях студии от 2012 до 2019, и абсолютно в каждой были глюки гуя. Не счесть раз, когда вместо изменения размера компонента он, словно поросенок Петр, уезжал куда-то влево на Запад. А как студия транслитерирует (например, при копировании) русские буквы...

2. Вы справились с непослушным интерфейсом и делаете коммит. И тут выясняется, что кто-то еще изменил этот пакет и надо смержить изменения. Но сделать это практически невозможно.

3. Старт SSIS проекта (пакета) относительно длителен и трудоемок. В отличие от скриптов SQL, его нельзя просто взять и отослать на компиляцию. Сначала серверу надо запустить хост-процесс issserver.exe, затем загрузить в него проект(пакет), распаковать и распарсить XML содержимое, загрузить библиотеки компонент, провалидировать потроха и соединения... (я мог чего-то не упомянуть, но мне уже лень перечислять и суть должна быть понятна).

4. У вас все загружается для локальной машины, но отказывается работать на сервере? Поздравляю: скорее всего, вы миллионный программист, столкнувшийся с различной битностью драйверов для 32-битной студии и 64-битного сервера.

Fox Malder,

так не продолжайте. Вас же не заставляют и не насилуют.

Если имеется несколько версий скрипта SQL, то значительную часть конфликтов между ними (кроме самых запущенных) можно разрешить посредством зрячих глаз и растущих из плечей (а не из задницы) рук. Ну а SSIS вполне в состоянии перемешать содержимое внутри пакета просто от нечего делать (был компонент описан первым, стал вторым, и наоборот) .

Далее, подавляющее большинство компонент SSIS остается практически без изменений с момента создания. Никто ничего не улучшает и не исправляет - что прямым образом сказывается на их функциональности и удобстве использования. Ну почему бы не дать разработчику возможность скопировать несколько строк из трансформации или в нее (имя, формула и др. поля) ? Сколько можно ставить признак сортировки в источнике через задний проход? Доколе оракловый Number будет грузиться через строку юникода (по умолчанию)? Когда в источники с соединениями ADO можно будет нормально (как в OLEDB) передавать параметры? (хотя называть знаки вопроса нормальным - это...) Почему надо внедрить несколько компонент для Хадупа и OData, но полностью забить на архивацию, SFTP или простую запись в лог пользовательского сообщения?

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