Pull to refresh

Comments 7

Возможно это хорошая инструкция в вашей компании, где все однообразно. Но для статьи тут информация только в том, куда кликать, если вы первый раз в SSIS.
К сожалению, больше тут нет ничего интересного, включая, почему выбраны именно такие опции, а не другие. Не говоря про то, что пример выбран мало того что идеальный для ETL, так еще и решаемый легко в рамках стандартного SQL-92.

Предупреждаю о недостатках этого инструмента.


Во-первых, он очень плохо стыкуется с DVCS.


Во-вторых, невозможно писать обобщенный код. И даже кодогенерация особо не помогает из-за закрытости форматов. Когда мне пришлось сделать однотипные операции над 30 таблицами — оказалось, что проще переписать все целиком на C# чем накликивать 120 элементов в визуальном редакторе.


В-третьих, отсутствие нормальной расширяемости. SSIS предлагает два способа сделать свой компонент — это ScriptComponent и PipelineComponent.


Но для ScriptComponent создается отдельный C#-проект во временной папке, который потом целиком упаковывается в один большой XML-файл. Это, в частности, означает нулевую переиспользуемость кода — в такой проект нельзя добавить библиотеку!


Что же до PipelineComponent — вроде бы вещь хорошая, но требуется точное соответствие версий и разрядности студии и SQL сервера, в противном случае сделанный вами компонент просто не появится в тулбоксе.

Поддержу. 2-3 летний проект, частично сделанный на версии 2008 этого инструмента, постоянно возникало желание все выбросить, и переписать заново.

К уже сказанному могу добавить следующее:
— ужасно неудобно работать с чужим проектом. Найти что-либо, понять, где формируется скажем значение какой-то колонки — практически не реально. Это означает нулевую сопровождаемость написанного.
— с не DVCS он тоже плохо стыкуется. Попробуйте понять, что изменилось в вашем проекте между ревизиями.
— если у вас изменились метаданые в какой-то из таблиц, проект зачастую просто перестает работать. Даже если на уровне SQL все осталось совместимо (т.е. мы не меняли скажем тип с varchar на int). Бороться с этим ужасно муторно.

Есть кстати некий проект, где предлагается писать пакеты SSIS на F#. В виде кода. Частично поддерживается импорт готовых проектов, сделанных в VS.

Не знаю, что там в версии 2014, а 2008 однозначно никому бы не посоветовал. Я пробовать переписывать куски на Java + Camel — обычно получалось значительно проще, понятнее, и как правило быстрее.
Работал с год на этой технологии. Мрак и ужас. Тот самый продукт который гораздо удобнее пилить через конфиг, ибо UI ужасен. Точнее, создать пакет можно и через UI, но мелкие доработки гораздо удобнее вносить через F7 (раскрывает XML файл описывающий выбранный в Solution Explorer пакет).

Плюс проблемы с тестированием. Если в пакете обычная передача данных — все еще более-менее нормально, но добавление любой логики превращает тесты в монстра.

P.S. Ого, да я не одинок!

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

Довелось потрогать небольшой biml файл- это ужас и кошмар. Работает в VS2013 максимум, отладка- через боль и страдания. Соболезную вам.

Просто пидорская поделка от MS (не в обиду гомосексуалистам будет сказано).

Sign up to leave a comment.

Articles