Les programmeurs devraient-ils utiliser SSIS, et si oui, pourquoi? [fermé]

En tant que développeur .NET, pour quelles raisons devrais-je préférer les packages SSIS à l'écriture de code? Nous avons une tonne de paquets en production sur lesquels je travaille actuellement, et c'est un cauchemar à la fois à «écrire» (peut-être dessiner?) Et à maintenir. Chaque paquet ressemble à un bol de spaghettis multicolores avec des scripts C # et VB.NET mélangés aux points où les abstractions se décomposent. Pour comprendre ce que fait chaque "Exécuter une tâche SQL" ou "Foreach Loop", je dois double-cliquer sur cette fichue chose et parcourir un arbre de valeurs et d'expressions littérales, dispersées sur plusieurs onglets.

Je suis ouvert d'esprit, donc j'aimerais savoir si d'autres bons développeurs trouvent SSIS plus productif que la simple écriture de code. Si vous trouvez SSIS plus productif, dites-moi pourquoi.

J'utilise SSIS tous les jours pour maintenir et gérer un grand entrepôt de données et un cube. Je suis 100% business intelligence et data warehouse depuis deux ans. Avant cela, j'étais développeur d'applications .NET pendant 10 ans.

La valeur de SSIS est en tant que moteur de flux de travail pour déplacer les données d'un endroit à un autre avec peut-être une transformation limitée et un branchement conditionnel en cours de route. Si vos packages contiennent beaucoup de scripts, votre équipe utilise SSIS pour les mauvaises tâches ou n'est pas à l'aise avec SQL ou a adhéré au battage médiatique. Les packages SSIS sont très difficiles à déboguer. Les composants de script sont un cauchemar absolu et ne doivent être utilisés que pour le formatage, la mise en boucle ou en dernier recours.

1. Gardez vos packages simples, les tâches SQL et les tâches de flux de données.
2. Faites autant de travail que possible en dehors de SSIS, de préférence en SQL
3. Conservez vos variables dans une seule portée globale
4. Gardez votre SQL dans des variables ou des procédures de stockage, jamais en ligne
5. Conservez vos valeurs de variable dans un magasin de configuration, de préférence une base de données SQL

J'ai essayé plusieurs fois d'utiliser SSIS et j'ai abandonné. IMO, il est beaucoup plus facile de faire tout ce dont j'ai besoin en C #. SSIS est trop complexe, il a trop de pièges et il n'en vaut tout simplement pas la peine. Il est préférable de passer plus de temps à améliorer les compétences C # que de passer le même temps à apprendre SSIS - vous obtiendrez beaucoup plus de retour sur votre formation.

La recherche et la maintenance des fonctionnalités dans une solution VS sont également beaucoup plus faciles. Les tests unitaires avec VS sont faciles. Tout ce que j'ai à faire est de vérifier la source dans Subversion et de vérifier comment elle s'est chargée. Les tests unitaires des packages SSIS sont très compliqués pour le dire légèrement.

En outre, il y avait des situations où SSIS échouait silencieusement à remplir certaines colonnes dans certaines lignes, les ignorant simplement sans lever d'exceptions. Nous avons passé beaucoup de temps à dépanner et à comprendre ce qui se passe. Le développement d'une solution alternative en C # a pris moins d'une heure et fonctionne sans aucun problème pendant deux ans.

À mon avis - SSIS est pour les opérations ETL uniquement et ne devrait contenir aucune logique en dehors de cette portée.

J'ai eu la malheureuse expérience de travailler sur un projet où nous pensions que SSIS serait une solution suffisante pour agréger et combiner des données provenant de plusieurs sources. Le malheur était que cela fonctionnait très bien au début, mais les exigences ont ensuite changé et nous avons (finalement) réalisé que c'était le mauvais outil.

peut-être que nous ne l'utilisions pas correctement, mais nous avons eu beaucoup de difficultés si nous changions de schéma et nous avons finalement simplement réutilisé nos définitions ORM du front-end pour écrire un outil personnalisé en C # pour ce faire. Parce que nous avions déjà le datamodel, c'était étonnamment facile. évidemment YMMV et je ne suis en aucun cas un expert SSIS, mais dans ce cas, SSIS a causé beaucoup de travail en double et de maux de tête en retroussant simplement nos manches et en «codant à la main», c'était plus facile que prévu.

Donc, je penserais beaucoup à la flexibilité lorsque je considère SSIS.

SSIS a sa place, et cet endroit n'est pas la programmation générale ou en remplacement des procédures stockées. Il vient de l'école ETL (Extraire, Transformer et Charger) et c'est là que se trouve sa solidité.

L'ancien nom (DTS, Data Transformation Services) et le nouveau nom (SSIS, Sql Server Integration Services) indiquent clairement qu'il s'agit d'un service (ou d'un ensemble de services) conçu pour manipuler les données afin d'intégrer la base de données SQL Server dans des processus plus volumineux.

Si vous souhaitez déplacer vos données par programmation, vous pouvez consulter Rhino ETL.

Je travaille également sur mon propre framework, Fluent ETL , car je trouve SSIS un peu trop impliqué pour les tâches de données simples liées au développement, comme le chargement de données de test unitaire à partir d'un fichier CSV.

SSIS n'est pas un programme. Beaucoup de choses sont plus rapides à faire dans SSIS, et vous obtenez de très belles informations détaillées sur la progression et les erreurs en tant qu'administrateur - ce qui peut être très bon dans les scénarios que SSIS est censé résoudre, car parfois les choses tournent mal et l'administrateur a besoin de beaucoup de information.

Cela étant dit, SSIS n'est pas vraiment utile si vous ne disposez pas des éléments auto-explicatifs - ils sont destinés à quelque chose, trop entrer dans la programmation générale les rend nul.