Les programmeurs devraient-ils utiliser SSIS, et si oui, pourquoi?

Question

Comme une .NET développeur, pour quelles raisons devrais-je préfère les packages SSIS sur l'écriture de code? Nous avons une tonne de paquets dans la production où je travaille actuellement, et ils sont un cauchemar à la fois à "écrire" (peut-être s'inspirer?) et à entretenir. Chaque paquet ressemble à un bol de multicolore spaghetti avec C# et VB.NET les scripts mixte dans les points où les abstractions briser. Pour déterminer ce que chaque "Tâche d'Exécution SQL" ou "Boucle Foreach", j'ai double cliquer sur la chose maudite et de parcourir un arbre de valeurs littérales et expressions, dispersés dans plusieurs onglets.

Je suis ouvert d'esprit, donc je voudrais savoir si d'autres bons développeurs trouver SSIS plus productif que d'écrire un peu de code. Si vous ne trouvez SSIS plus productif, s'il vous plaît dites-moi pourquoi.

Answer 1

J'utilise SSIS chaque jour pour maintenir et gérer un grand entrepôt de données et le cube. J'ai eu 100% de business intelligence et de l'entreposage de données pour les deux années. Avant que j'étais un .NET développeur de l'application pour 10.

La valeur de SSIS est comme un moteur de workflow pour déplacer des données d'un endroit à un autre avec peut-être quelques limitée de transformation et de branchements conditionnels le long du chemin. Si vos paquets contiennent beaucoup de script puis votre équipe est à l'aide de SSIS pour le mal de tâches ou n'est pas à l'aise avec SQL ou a acheté dans le hype. Les packages SSIS sont très difficiles à déboguer. Les composants de Script sont un cauchemar absolu et doit être utilisé uniquement pour la mise en forme, en boucle, ou en dernier recours.

1. Gardez vos paquets simples, sql tâches et les tâches de flux de données.
2. Faire autant de travail que possible à l'extérieur de la SSIS, de préférence dans SQL
3. Gardez vos variables dans une seule portée mondiale
4. Gardez votre SQL dans des variables ou des procédures de la banque, de ne jamais en ligne
5. Gardez vos valeurs d'une variable dans un magasin de configuration, de préférence une base de données SQL

Answer 2

J'ai essayé d'utiliser SSIS à plusieurs reprises, et a abandonné. OMI, il est beaucoup plus facile de faire tout ce dont j'ai besoin dans C#. SSIS est trop complexe, il y a trop de pièges, et c'est juste pas la peine. Il est beaucoup mieux de passer plus de temps sur l'amélioration de C# de compétences que de passer en même temps sur l'apprentissage SSIS - vous obtiendrez beaucoup plus de retour sur votre formation.

Aussi la recherche et le maintien de la fonctionnalité dans un VS solution est donc beaucoup plus facile. Tests unitaires avec VS est facile. Tout ce que j'ai à faire est de vérifier dans la source de Subversion, et de vérifier la façon dont il est chargé. Les tests unitaires des packages SSIS est très impliqué et c'est un euphémisme.

En outre, il y a des situations quand SSIS était silencieusement à défaut de remplir certaines colonnes en quelques lignes, juste sauter sans soulever des exceptions. Nous avons passé beaucoup de temps dans la résolution et de comprendre ce qui se passe. Développement d'une solution de rechange en C# a pris moins d'une heure, et fonctionne sans problème depuis deux ans.

Answer 3

I mon opinion - SSIS concerne uniquement les opérations ETL et ne doit contenir aucune logique en dehors de cette portée.

Answer 4

J'ai eu la malheureuse expérience de travail sur un projet où nous avons pensé SSIS serait une assez bonne solution pour regrouper et combiner des données provenant de plusieurs sources. Le malheureux, c'est qu'il a très bien fonctionné au début, mais ensuite changé et nous avons (enfin) rendu compte que c'était le mauvais outil.

nous avons peut-être juste de l'utilisation erronée, mais nous avons eu beaucoup de difficulté si jamais nous avons changé notre schéma et nous avons finalement simplement de les réutiliser notre ORM définitions de l'extrémité avant d'écrire un outil personnalisé en C# pour ce faire. Parce que nous avons déjà eu le datamodel cela a été étonnamment facile. évidemment, YMMV et je ne suis en aucun cas SSIS expert, mais dans ce cas SSIS causé beaucoup de travail en double et des maux de tête quand il suffit de retrousser nos manches et de "handcoding", il a été plus facile que prévu.

Donc, je pense que sur la flexibilité d'un lot lors de l'examen SSIS.

Answer 5

SSIS a sa place, et cette place n'est pas une programmation générale ou ne remplace pas des procédures stockées. Il vient de l'école ETL (Extract, Transform, and Load) et c'est là que se trouve sa force.

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 des données afin d'intégrer la base de données SQL Server à des processus plus importants.