Comments 7
Возможно это хорошая инструкция в вашей компании, где все однообразно. Но для статьи тут информация только в том, куда кликать, если вы первый раз в SSIS.
К сожалению, больше тут нет ничего интересного, включая, почему выбраны именно такие опции, а не другие. Не говоря про то, что пример выбран мало того что идеальный для ETL, так еще и решаемый легко в рамках стандартного SQL-92.
Предупреждаю о недостатках этого инструмента.
Во-первых, он очень плохо стыкуется с DVCS.
Во-вторых, невозможно писать обобщенный код. И даже кодогенерация особо не помогает из-за закрытости форматов. Когда мне пришлось сделать однотипные операции над 30 таблицами — оказалось, что проще переписать все целиком на C# чем накликивать 120 элементов в визуальном редакторе.
В-третьих, отсутствие нормальной расширяемости. SSIS предлагает два способа сделать свой компонент — это ScriptComponent и PipelineComponent.
Но для ScriptComponent создается отдельный C#-проект во временной папке, который потом целиком упаковывается в один большой XML-файл. Это, в частности, означает нулевую переиспользуемость кода — в такой проект нельзя добавить библиотеку!
Что же до PipelineComponent — вроде бы вещь хорошая, но требуется точное соответствие версий и разрядности студии и SQL сервера, в противном случае сделанный вами компонент просто не появится в тулбоксе.
К уже сказанному могу добавить следующее:
— ужасно неудобно работать с чужим проектом. Найти что-либо, понять, где формируется скажем значение какой-то колонки — практически не реально. Это означает нулевую сопровождаемость написанного.
— с не DVCS он тоже плохо стыкуется. Попробуйте понять, что изменилось в вашем проекте между ревизиями.
— если у вас изменились метаданые в какой-то из таблиц, проект зачастую просто перестает работать. Даже если на уровне SQL все осталось совместимо (т.е. мы не меняли скажем тип с varchar на int). Бороться с этим ужасно муторно.
Есть кстати некий проект, где предлагается писать пакеты SSIS на F#. В виде кода. Частично поддерживается импорт готовых проектов, сделанных в VS.
Не знаю, что там в версии 2014, а 2008 однозначно никому бы не посоветовал. Я пробовать переписывать куски на Java + Camel — обычно получалось значительно проще, понятнее, и как правило быстрее.
Плюс проблемы с тестированием. Если в пакете обычная передача данных — все еще более-менее нормально, но добавление любой логики превращает тесты в монстра.
P.S. Ого, да я не одинок!
И я тоже с праведным гневом пну калеку, который до сих пор ест мои нервы. Сам по себе SSIS — неплохой движок. Но средства разработки под него просто кошмарны, представляют собой мешанину из мастеров и вставляемых сниппетов кода. И возможности писать пакеты без этой штуки тоже никакой, т.к. они представляют собой внушительные XML, не предназначенные для восприятия человеком. И к тому же возникает ощущение, что Microsoft забросила этот инструмент, т.к. там, по сути, нет развития этак с версии 2008.
Просто пидорская поделка от MS (не в обиду гомосексуалистам будет сказано).
SQL Server Integration Services (SSIS) для начинающих – часть 1