Non vorrei avere 200 flussi di dati in un unico pacchetto. Il tempo necessario per aprire e validare ti renderebbe vecchio prima del tuo tempo.
EzAPI è divertente ma se sei nuovo su .NET e SSIS, oh no, non lo vuoi. Penso che passerai molto più tempo a conoscere il modello a oggetti SSIS e possibilmente a gestire COM che a lavorare davvero.
Dato che sono pigro, collegherò BIML come opzione gratuita che non hai elencato. Da una risposta su SO /programming/13809491/generating-several-similar-ssis-packages-file-data-source-to-db/13809604#13809604
- Biml è una bestia interessante. Varigence sarà felice di venderti una licenza per Mist, ma non è necessario. Tutto ciò di cui hai bisogno è BIDSHelper e quindi sfogliare BimlScript e cercare una ricetta che si avvicini alle tue esigenze. Una volta che lo hai fatto, fai clic sul pulsante del menu sensibile al contesto in BIDSHelper e whoosh, genera pacchetti.
Penso che potrebbe essere un approccio anche per te. Definisci il tuo BIML che descrive il comportamento dei pacchetti e quindi li genera. Nello scenario in cui descrivi dove apporti una modifica e devi correggere N pacchetti, no, correggi la tua definizione del problema e rigenera i pacchetti.
O se hai acquisito sufficiente familiarità con il framework, usa qualcosa come EzAPI per andare a riparare tutte le cose rotte. Diamine, dato che l'hai etichettato come 2005, potresti anche provare PacMan se hai bisogno di apportare modifiche di massa ai pacchetti esistenti.
Considerazioni sulla progettazione di SSIS
In generale, provo a concentrare i miei pacchetti sulla risoluzione di una singola attività (caricamento dei dati di vendita). Se ciò richiede 2 flussi di dati, così sia. Ciò che odio ereditare è un pacchetto dalla procedura guidata di importazione / esportazione con molti flussi di dati non correlati in un singolo pacchetto. Scomporli in qualcosa che risolva un problema molto specifico. Rende i miglioramenti futuri meno rischiosi poiché la superficie è ridotta. Un ulteriore vantaggio è che posso lavorare sul caricamento DimProductsmentre il mio servitore si occupa del caricamento del SnowflakeFromHellpacchetto.
Quindi utilizzare i pacchetti principali per orchestrare i flussi di lavoro secondari. So che sei nel 2005, ma la versione di SQL Server 2012 di SSIS è il pigiama del gatto. Adoro il modello di implementazione del progetto e la stretta integrazione che consente tra i pacchetti.
TSQL vs SSIS (la mia storia)
Per quanto riguarda il puro approccio TSQL, in un precedente lavoro hanno utilizzato un lavoro in 73 passaggi per replicare tutti i loro dati Informix in SQL Server. In genere ci sono voluti circa 9 ore ma potrebbe allungarsi a circa 12. Dopo aver acquistato una nuova SAN, è passata a circa 7+ ore. Lo stesso processo logico, riscritto in SSIS è stato un consistente sotto 2 ore. Facilmente il fattore più importante nel ridurre quel tempo è stata la parallelizzazione "libera" che abbiamo ottenuto utilizzando SSIS. Il processo dell'agente ha eseguito tutte queste attività in serie. Il pacchetto principale ha sostanzialmente diviso le tabelle in unità di elaborazione (5 serie parallele di attività serializzate di "esegui replicate tabella 1", tabella 2, ecc.) In cui ho cercato di dividere i bucket in unità di lavoro quasi uguali. Ciò ha consentito di popolare rapidamente le 60 tabelle di riferimento di ricerca e quindi l'elaborazione ha rallentato man mano che entrava nella "
Un altro vantaggio per me che utilizzo SSIS è che ottengo una configurazione "libera", la registrazione e l'accesso alle librerie .NET per i dati quadrati che devo colpire in un foro circolare. Penso che possa essere più facile mantenere (passare la manutenzione) un pacchetto SSIS che un approccio TSQL puro in virtù della natura grafica della bestia.
Come sempre, il tuo chilometraggio può variare.