Следует ли программистам использовать SSIS, и если да, то почему? [закрыто]

Как разработчик .NET, по каким причинам я должен предпочесть пакеты SSIS написанию кода? У нас есть масса пакетов в производстве, где я сейчас работаю, и это кошмар как для «написания» (возможно, рисования?), Так и для поддержки. Каждый пакет выглядит как миска с разноцветными спагетти со скриптами C # и VB.NET, смешанными в точках, где абстракции ломаются. Чтобы понять, что делает каждая «задача выполнения SQL» или «цикл по каждому элементу», мне нужно дважды щелкнуть эту проклятую вещь и просмотреть дерево буквальных значений и выражений, разбросанных по нескольким вкладкам.

У меня открытые взгляды, поэтому я хотел бы знать, считают ли другие хорошие разработчики 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, Data Transformation Services) и новое имя (SSIS, Sql Server Integration Services) ясно дают понять, что это служба (или набор служб), предназначенная для манипулирования данными для интеграции базы данных SQL Server в более крупные процессы.

Если вы хотите переместить данные программно, вам стоит взглянуть на Rhino ETL.

Я также работаю над своей собственной структурой Fluent ETL , поскольку считаю, что SSIS слишком задействован для простых задач с данными, связанных с разработкой, таких как загрузка данных модульного теста из файла CSV.

SSIS - это не программа. Многие задачи в SSIS выполнять быстрее, и вы получаете очень хорошую подробную информацию о прогрессе и ошибках как администратор, что может быть очень хорошо в сценариях, которые SSIS предназначен для решения, потому что иногда что-то идет не так, и администратору нужно много Информация.

При этом SSIS на самом деле не так полезен, если у вас нет этого материала для самостоятельного объяснения - они предназначены для чего-то, слишком много погружаясь в общее программирование, делает их отстой.