Les programmeurs devraient-ils utiliser SSIS, et si oui, pourquoi?
En tant que développeur .NET, pour quelles raisons devrais-je préférer les packages SSIS à l'écriture de code? Nous avons ne tonne de packages en production où je travaille actuellement, et ils sont 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 "Boucle Foreach", je dois double-cliquer sur la fichue chose et parcourir une arborescence 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 d'écrire du 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 pour 10.
La valeur de SSIS est un moteur de flux de travail pour déplacer les données d'un endroit à un autre avec peut-être une transformation limitée et une ramification conditionnelle 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 boucle ou en dernier recours.
- Gardez vos packages simples, tâches SQL et tâches de flux de données.
- Faites autant de travail que possible en dehors de SSIS, de préférence en SQL
- Gardez vos variables dans une seule portée globale
- Gardez votre SQL dans des variables ou des procédures de stockage, jamais en ligne
- Conservez vos valeurs de variables dans un magasin de configuration, de préférence une base de données SQL
J'ai essayé d'utiliser SSIS plusieurs fois et j'ai abandonné. OMI, 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 cela n'en vaut pas la peine. Il est préférable de consacrer plus de temps à l'amélioration des compétences C # que de consacrer le même temps à l'apprentissage de SSIS - vous obtiendrez un retour sur votre formation beaucoup plus important.
Il est également beaucoup plus facile de trouver et de maintenir des fonctionnalités dans une solution VS. Les tests unitaires avec VS sont faciles. Tout ce que je dois 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 impliqués pour le moins.
En outre, il y avait des situations où SSIS échouait silencieusement à remplir certaines colonnes de certaines lignes, les ignorant simplement sans lever d'exceptions. Nous avons passé beaucoup de temps à dépanner et à comprendre ce qui se passait. Le développement d'une solution alternative en C # a pris moins d'une heure et fonctionne sans problème pendant deux ans.
À mon avis - SSIS est uniquement destiné aux opérations ETL et ne doit 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 assez bonne solution 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 ensuite les exigences ont changé et nous avons (finalement) réalisé que ce n'était pas le bon outil.
peut-être que nous l'utilisions simplement de manière incorrecte, mais nous avons eu beaucoup de difficultés si nous changions un jour notre schéma et nous avons finalement simplement réutilisé nos définitions ORM à partir du frontal pour écrire un outil personnalisé en C # pour ce faire. Parce que nous avions déjà le modèle de données, 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 quand nous avons simplement retroussé nos manches et que le `` codage manuel '' a été plus facile que prévu.
Je penserais donc beaucoup à la flexibilité lors de l'examen de SSIS.
SSIS a sa place, et cette place n'est pas une 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 son stregnth.
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 ensemble de services) conçu pour manipuler des données afin d'intégrer la base de données SQL Server dans des processus plus importants.
Si vous souhaitez déplacer vos données par programme, vous pouvez regarder Rhino ETL.
Je travaille également sur mon propre framework, Fluent ETL , car je trouve que SSIS est 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 n'avez pas les choses auto-explicatives - elles sont destinées à quelque chose, entrer trop dans la programmation générale les rend folles.