Чи повинні програмісти використовувати SSIS, і якщо так, то чому? [зачинено]

Як розробник .NET, з яких причин я повинен віддавати перевагу пакетам SSIS перед написанням коду? У нас є тонна пакетів на виробництві, де я зараз працюю, і вони кошмарують як „писати” (можливо, малювати?), Так і підтримувати. Кожен пакет виглядає як чаша різнокольорових спагетті зі змішаними сценаріями C # та VB.NET у місцях, де абстракції руйнуються. Щоб зрозуміти, що робить кожне "Виконання SQL-завдання" або "Foreach Loop", мені потрібно двічі клацнути цю прокляту річ і переглянути дерево буквальних значень і виразів, розподілених по декількох вкладках.

Я відкритий, тому хотів би знати, чи вважають якісь інші хороші розробники SSIS продуктивнішим, ніж просто написання коду. Якщо ви вважаєте SSIS більш продуктивним, скажіть, чому.

Я використовую SSIS щодня для обслуговування та управління великим сховищем даних та кубом. Я вже два роки займаюся 100% бізнес-аналітикою та зберіганням даних. До цього я був розробником програми .NET протягом 10 років.

Значення SSIS - це механізм робочого процесу для переміщення даних з одного місця в інше, можливо, з деяким обмеженим перетворенням та умовним розгалуженням. Якщо ваші пакунки містять багато сценаріїв, тоді ваша команда використовує SSIS для неправильних завдань, або не влаштовує SQL, або придбала хайп. Пакети SSIS дуже важко налагодити. Компоненти сценарію є абсолютним кошмаром і повинні використовуватися лише для форматування, циклу або в крайньому випадку.

1. Зберігайте свої пакети простими, завданнями sql та завданнями потоку даних.
2. Робіть якомога більше роботи поза SSIS, бажано в SQL
3. Зберігайте свої змінні в єдиному глобальному масштабі
4. Зберігайте свій SQL у змінних або зберігайте процедури, ніколи не в рядку
5. Зберігайте значення змінних у сховищі конфігурацій, бажано базі даних SQL

Я кілька разів намагався використовувати SSIS і відмовився від нього. ІМО набагато простіше просто зробити все, що мені потрібно в C #. SSIS занадто складний, у нього занадто багато помилок, і це просто не варто. Набагато краще витрачати більше часу на вдосконалення навичок C #, ніж витрачати той самий час на вивчення SSIS - ви отримаєте набагато більше віддачі від свого навчання.

Також знайти та підтримувати функціональність рішення VS набагато простіше. Модульне тестування за допомогою VS легко. Все, що мені потрібно зробити, це перевірити джерело в Subversion і перевірити, як воно завантажилося. Модульне тестування пакетів SSIS, м’яко кажучи, дуже задіяне.

Крім того, траплялися ситуації, коли SSIS мовчки не могла заповнювати деякі стовпці в деяких рядках, просто пропускаючи їх, не створюючи винятків. Ми витратили багато часу на усунення несправностей та з’ясування того, що відбувається. Розробка альтернативного рішення на C # зайняла менше години і працює без проблем два роки.

На мій погляд - SSIS призначений лише для операцій ETL і не повинен містити жодної логіки поза цим обсягом.

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

можливо, ми просто використовували його неправильно, але у нас було багато труднощів, якщо ми коли-небудь змінювали нашу схему, і врешті-решт ми просто використовували наші визначення ORM з інтерфейсу, щоб написати власний інструмент в C # для цього. Оскільки ми вже мали модель даних, це було напрочуд легко. очевидно YMMV, і я ні в якому разі не є експертом SSIS, але в цьому одному випадку SSIS викликав багато дублюючих робіт та головних болів, коли просто закатавши рукави та "ручне кодування" було простіше, ніж очікувалося.

Тому я б багато думав про гнучкість, розглядаючи SSIS.

SSIS має своє місце, і це місце не є загальним програмуванням або заміною збереженим процедурам. Він походить зі школи ETL (Витяг, Трансформація та Навантаження), і саме тут його напрямок.

Старе ім'я (DTS, Служба перетворення даних) і нове ім'я (SSIS, Служби інтеграції серверів Sql) однозначно дають зрозуміти, що це послуга (або набір служб), призначена для маніпулювання даними для інтеграції бази даних SQL Server у великі процеси.

Якщо ви хочете перемістити дані програмно, ви можете подивитися на Rhino ETL.

Я також працюю над власним фреймворком, Fluent ETL , оскільки вважаю, що SSIS занадто задіяний для простих завдань, пов'язаних з розробкою даних, таких як завантаження тестових даних з файлу CSV.

SSIS - це не програма. Багато знаків швидше роблять у SSIS, і ви отримуєте дуже приємну детальну інформацію про хід і помилки в якості адміністратора - що може бути дуже добре в сценаріях, призначених для вирішення SSIS, тому що іноді все йде не так, і адміністратору потрібно багато інформація.

Тим не менш, SSIS насправді не такий корисний, якщо у вас немає матеріалів, які можна пояснити самостійно - вони призначені для чогось, занадто багато загального програмування робить їх неприємними.