Eu não gostaria de ter 200 fluxos de dados em um único pacote. O tempo que levaria apenas para abrir e validar o deixaria velho antes do tempo.
O EzAPI é divertido, mas se você é novo no .NET e SSIS, oh não, não quer isso. Eu acho que você gastará muito mais tempo aprendendo sobre o modelo de objeto SSIS e possivelmente lidando com COM do que realmente fazendo o trabalho.
Como sou preguiçoso, vou conectar o BIML como uma opção gratuita que você não listou. De uma resposta no SO /programming/13809491/generating-several-similar-ssis-packages-file-data-source-to-db/13809604#13809604
- Biml é uma fera interessante. A Varigence terá prazer em vender uma licença para a Mist, mas isso não é necessário. Tudo que você precisa é BIDSHelper e, em seguida, navegue pelo BimlScript e procure uma receita que se aproxime de suas necessidades. Depois disso, clique no botão de menu sensível ao contexto no BIDSHelper e whoosh, ele gera pacotes.
Eu acho que pode ser uma abordagem para você também. Você define seu BIML que descreve como seus pacotes devem se comportar e os gera. No cenário, você descreve onde faz uma alteração e precisa corrigir N pacotes; não, você corrige sua definição do problema e gera novamente os pacotes.
Ou, se você adquiriu familiaridade suficiente com a estrutura, use algo como EzAPI para consertar todas as coisas quebradas. Heck, já que você marcou isso em 2005, você também pode tentar o PacMan se precisar fazer modificações em massa nos pacotes existentes.
Considerações de design do SSIS
De um modo geral, tento focar meus pacotes na solução de uma única tarefa (carregar dados de vendas). Se isso requer 2 fluxos de dados, que seja. O que eu odeio herdar é um pacote do assistente de exportação e importação com muitos fluxos de dados não relacionados em um único pacote. Decomponha-os em algo que resolva um problema muito específico. Isso torna as melhorias futuras menos arriscadas à medida que a área de superfície é reduzida. Um benefício adicional é que eu posso trabalhar no carregamento DimProductsenquanto meu lacaio lida com o carregamento do SnowflakeFromHellpacote.
Em seguida, use o (s) pacote (s) mestre (s) para orquestrar os fluxos de trabalho filho. Eu sei que você está em 2005, mas o lançamento do SSIS no SQL Server 2012 é o pijama do gato. Adoro o modelo de implantação do projeto e a forte integração que ele permite entre pacotes.
TSQL vs SSIS (minha história)
Quanto à abordagem TSQL pura, em um trabalho anterior, eles usaram um trabalho de 73 etapas para replicar todos os dados do Informix no SQL Server. Geralmente, levava cerca de 9 horas, mas podia chegar a 12 ou mais. Depois que eles compraram uma nova SAN, ela caiu para mais de 7 horas. O mesmo processo lógico, reescrito no SSIS, foi consistente em 2 horas. Facilmente, o maior fator para reduzir esse tempo foi a paralelização "livre" que obtivemos usando o SSIS. O trabalho do agente executou todas essas tarefas em série. O pacote principal basicamente dividiu as tabelas em unidades de processamento (5 conjuntos paralelos de tarefas serializadas de "executar tabela replicada 1", tabela 2, etc.), onde tentei dividir os baldes em unidades de trabalho quase iguais. Isso permitiu que as cerca de 60 tabelas de referência de pesquisa fossem preenchidas rapidamente e, em seguida, o processamento diminuiu quando entrou no "
Outras vantagens para mim usando o SSIS é que eu recebo configuração "gratuita", registro e acesso às bibliotecas .NET para dados quadrados que preciso basear em um buraco redondo. Eu acho que pode ser mais fácil manter (repassar a manutenção) um pacote SSIS do que uma abordagem TSQL pura em virtude da natureza gráfica da besta.
Como sempre, sua milhagem pode variar.