Comprende el código correctamente antes de utilizarlo a tu trabajo y si tquieres aportar algo puedes compartirlo con nosotros.
Solución:
Si su ETL es principalmente E y L, con muy poca T, y si puede escribir sus SP para que no dependan de los cursores, entonces la ruta de solo SP probablemente esté bien.
Para procesos más complejos, particularmente aquellos que involucran transformaciones pesadas, dimensiones que cambian lentamente, búsquedas de minería de datos, etc., SSIS tiene tres ventajas.
Primero, administra la memoria de manera muy eficiente, lo que puede resultar en grandes mejoras de rendimiento en comparación con T-SQL solo.
En segundo lugar, la interfaz gráfica le permite crear transformaciones grandes, complejas y confiables mucho más fácilmente que T-SQL hecho a mano.
Y tercero, SSIS le permite interactuar más fácilmente con fuentes externas adicionales, lo que puede ser muy útil para cosas como la limpieza de datos.
He vivido en la tierra del procedimiento almacenado ETL para un almacén de datos de SQL Server de varios terabytes. Esta decisión se tomó en 2001 cuando .NET era 1.0, por lo que VB6 era la alternativa del lenguaje de programación y SSIS aún no existía: era DTS. Te puedo decir que hubo ventajas y desventajas, como cualquier cosa.
Algunas consideraciones:
- Si todos en su equipo entienden SQL, es fácil profundizar en los procesos almacenados. SQL es una habilidad ampliamente conocida que puede ser un beneficio si tiene muchos escritores/lectores de ETL. Tiene que ser más que un usuario casual de SSIS para entender lo que está haciendo. El flujo gráfico de alto nivel es bueno para la documentación, pero si alguien necesita profundizar, es mejor que conozca bien SSIS.
- SQL es un dolor de modularizar. Si usa UDF, sufrirá un gran impacto en el rendimiento. Escribirá un código similar en varios lugares y se odiará a sí mismo por hacerlo, pero a menudo en los escenarios de ETL, el rendimiento es el rey. SSIS lo ayudará a modularizar y factorizar sus tareas.
- No espere poder usar fácilmente el control de código fuente con SSIS. SQL: no hay problema. SSIS usa archivos XML horribles que se pueden registrar, pero buena suerte al comparar con versiones anteriores para ver qué cambió y cuándo.
- Debe pensar en sus SP de forma modular, aunque es difícil hacerlos tan modulares como le gustaría. Use tablas temporales para fragmentar su procesamiento. Coloque índices en esas tablas temporales antes de usarlas. No trate de hacer demasiado a la vez. Comenta todo.
- Si estás usando cursores, lo estás haciendo mal. No tenga miedo de encadenar alguna aplicación de consola externa que haya escrito en el idioma de su elección para hacer algunas cosas para las que SQL simplemente no estaba hecho.
Por cierto, después de que dejé esa empresa, finalmente actualizaron la base de datos de SQL 2000 a 2008 y lentamente pasaron de los procesos almacenados a SSIS. En mi nueva empresa, somos dueños de SSIS, pero después de usarlo todos acordamos que nuestro .NET ETL personalizado se adapta mejor a nuestros propósitos. Cada uno toma su propia ruta. La decisión tiene que equilibrar el mantenimiento y el rendimiento y el conjunto de habilidades de su equipo y el conjunto de habilidades del grupo de trabajo en su área.
Estoy en medio de deshacerme de nuestros paquetes SSIS y usar procedimientos almacenados. Para nosotros, los procesos almacenados son tremendamente mejores:
- Son mucho más fáciles de mantener, no necesitamos ofertas, no necesitamos crear proyectos e importar paquetes en las ofertas, por lo tanto, hay muchos menos pasos para realizar cambios simples en los procesos almacenados.
- Todos nuestros paquetes actuales básicamente truncan los datos en una tabla, luego los vuelven a llenar desde varias otras tablas en el mismo servidor con asignaciones directas. Muy fácil Insertar/seleccionar SQL para escribir.
- Corren mucho más rápido. No tenemos cursores, ni estructuras de bucle, solo SQL directo.
- No tenemos que pasar todo nuestro tiempo haciendo clic derecho y trabajando en pequeñas ventanas de ofertas tratando de seguir el flujo de la lógica. Todos conocemos TSQL básico y eso es suficiente para nuestras tareas.