Je ne voudrais pas avoir 200 flux de données dans un seul package. Le temps qu'il faudrait pour s'ouvrir et valider vous ferait vieillir avant votre temps.
EzAPI est amusant, mais si vous êtes nouveau sur .NET et SSIS, oh non, vous n'en voulez pas. Je pense que vous passerez beaucoup plus de temps à vous familiariser avec le modèle objet SSIS et peut-être à gérer COM que de travailler réellement.
Puisque je suis paresseux, je vais brancher le BIML comme une option gratuite que vous n'avez pas listée. D'après une réponse sur SO /programming/13809491/generating-several-similar-ssis-packages-file-data-source-to-db/13809604#13809604
- Biml est une bête intéressante. Varigence se fera un plaisir de vous vendre une licence à Mist mais elle n'est pas nécessaire. Tout ce dont vous avez besoin est BIDSHelper , puis parcourez BimlScript et recherchez une recette qui correspond à vos besoins. Une fois que vous avez cela, cliquez sur le bouton de menu contextuel dans BIDSHelper et whoosh, il génère des packages.
Je pense que cela pourrait aussi être une approche pour vous. Vous définissez votre BIML qui décrit le comportement de vos packages, puis vous les générez. Dans le scénario, vous décrivez où vous apportez une modification et devez corriger N packages, non, vous corrigez votre définition du problème et régénérez les packages.
Ou si vous vous êtes suffisamment familiarisé avec le framework, utilisez quelque chose comme EzAPI pour réparer tous les problèmes. Heck, puisque vous avez marqué cela comme 2005, vous pouvez également essayer PacMan si vous avez besoin d'apporter des modifications en masse aux packages existants.
Considérations de conception SSIS
D'une manière générale, j'essaie de faire en sorte que mes packages se concentrent sur la résolution d'une seule tâche (charger les données de vente). Si cela nécessite 2 flux de données, tant pis. Ce que je déteste hériter est un package de l'assistant d'importation et d'exportation avec de nombreux flux de données non liés dans un seul package. Les décomposer en quelque chose qui résout un problème très spécifique. Cela rend les améliorations futures moins risquées car la surface est réduite. Un avantage supplémentaire est que je peux travailler sur le chargement DimProductspendant que mon serviteur s'occupe du chargement du SnowflakeFromHellpaquet.
Utilisez ensuite des packages principaux pour orchestrer les flux de travail enfants. Je sais que vous êtes en 2005, mais la version de SQL Server 2012 de SSIS est le pyjama du chat. J'adore le modèle de déploiement de projet et l'intégration étroite qu'il permet entre les packages.
TSQL vs SSIS (mon histoire)
Quant à l'approche TSQL pure, dans un travail précédent, ils ont utilisé un travail en 73 étapes pour répliquer toutes leurs données Informix dans SQL Server. Cela prenait généralement environ 9 heures, mais pouvait s'étendre à environ 12 heures. Après avoir acheté un nouveau SAN, il est tombé à environ 7 heures et plus. Même processus logique, réécrit dans SSIS était un sous 2 heures cohérent. Le parallélisme "gratuit" que nous avons obtenu avec SSIS a été le plus grand facteur de ralentissement. Le travail de l'agent a exécuté toutes ces tâches en série. Le package maître a essentiellement divisé les tables en unités de traitement (5 ensembles parallèles de tâches sérialisées de "exécuter la table de réplication 1", la table 2, etc.) où j'ai essayé de diviser les compartiments en unités de travail de taille quasi égale. Cela a permis à la soixantaine de tables de référence de recherche d'être remplies rapidement, puis le traitement a ralenti à mesure qu'il entrait dans le "
Un autre avantage pour moi en utilisant SSIS est que j'obtiens une configuration, une journalisation et un accès «gratuits» aux bibliothèques .NET pour les données carrées que je dois creuser dans un trou rond. Je pense qu'il peut être plus facile de maintenir (faire passer la maintenance) un paquet SSIS qu'une approche TSQL pure en raison de la nature graphique de la bête.
Comme toujours, votre kilométrage peut varier.