No quisiera tener 200 flujos de datos en un solo paquete. El tiempo que llevaría abrir y validar lo haría viejo antes de tiempo.
EzAPI es divertido, pero si eres nuevo en .NET y SSIS, oh, no, no quieres eso. Creo que pasará mucho más tiempo aprendiendo sobre el modelo de objetos SSIS y posiblemente lidiando con COM que realmente haciendo el trabajo.
Como soy flojo, conectaré BIML como una opción gratuita que no incluiste en la lista. De una respuesta en SO /programming/13809491/generating-several-similar-ssis-packages-file-data-source-to-db/13809604#13809604
- Biml es una bestia interesante. Varigence estará encantado de venderle una licencia a Mist, pero no es necesaria. Todo lo que necesita es BIDSHelper y luego navegue a través de BimlScript y busque una receta que se aproxime a sus necesidades. Una vez que tenga eso, haga clic en el botón de menú contextual en BIDSHelper y whoosh, genera paquetes.
Creo que también podría ser un enfoque para ti. Usted define su BIML que describe cómo deben comportarse sus paquetes y luego los genera. En el escenario que describe dónde realiza un cambio y tiene que arreglar N paquetes, no, arregla su definición del problema y regenera paquetes.
O si se ha familiarizado lo suficiente con el marco, use algo como EzAPI para arreglar todas las cosas rotas. Heck, ya que has etiquetado esto como 2005, también puedes probar PacMan si necesitas hacer modificaciones masivas a los paquetes existentes.
Consideraciones de diseño de SSIS
En términos generales, trato de hacer que mis paquetes se centren en resolver una sola tarea (cargar datos de ventas). Si eso requiere 2 flujos de datos, que así sea. Lo que odio heredar es un paquete del asistente de importación y exportación con muchos flujos de datos no relacionados en un solo paquete. Descompóngalos en algo que resuelva un problema muy específico. Hace que las mejoras futuras sean menos riesgosas a medida que se reduce el área de superficie. Un beneficio adicional es que puedo estar trabajando en la carga DimProductsmientras mi secuaz se ocupa de cargar el SnowflakeFromHellpaquete.
Luego use los paquetes maestros para orquestar los flujos de trabajo infantil. Sé que estás en 2005, pero el lanzamiento de SSIS de SQL Server 2012 es el pijama del gato. Me encanta el modelo de implementación del proyecto y la estrecha integración que permite entre paquetes.
TSQL vs SSIS (mi historia)
En cuanto al enfoque TSQL puro, en un trabajo anterior, utilizaron un trabajo de 73 pasos para replicar todos sus datos de Informix en SQL Server. En general, tomó alrededor de 9 horas, pero podría extenderse a 12 más o menos. Después de comprar una nueva SAN, se redujo a más de 7 horas. El mismo proceso lógico, reescrito en SSIS fue un sub 2 horas consistentes. Fácilmente, el factor más importante para reducir ese tiempo fue la paralelización "gratuita" que obtuvimos con SSIS. El trabajo del Agente ejecutó todas esas tareas en serie. El paquete maestro básicamente dividió las tablas en unidades de procesamiento (5 conjuntos paralelos de tareas serializadas de "ejecutar la tabla replicada 1", la tabla 2, etc.) donde intenté dividir los cubos en unidades de trabajo de tamaño casi igual. Esto permitió que las más o menos 60 tablas de referencia de búsqueda se rellenaran rápidamente y luego el proceso se ralentizó a medida que ingresaba en "
Otras ventajas para mí al usar SSIS es que obtengo configuración "gratuita", registro y acceso a las bibliotecas .NET para datos cuadrados que necesito para hacer un agujero redondo. Creo que puede ser más fácil mantener (pasar el mantenimiento) un paquete SSIS que un enfoque TSQL puro en virtud de la naturaleza gráfica de la bestia.
Como siempre, su kilometraje puede variar.