¿Deberían los programadores usar SSIS y, de ser así, por qué? [cerrado]

Como desarrollador de .NET, ¿por qué debería preferir los paquetes SSIS a la escritura de código? Tenemos un montón de paquetes en producción donde trabajo actualmente, y son una pesadilla tanto para "escribir" (¿quizás dibujar?) Como para mantenerlos. Cada paquete parece un cuenco de espaguetis multicolores con scripts de C # y VB.NET mezclados en los puntos donde se rompen las abstracciones. Para averiguar qué hace cada "Tarea Ejecutar SQL" o "Bucle Foreach", tengo que hacer doble clic en la maldita cosa y navegar a través de un árbol de valores y expresiones literales, dispersos en múltiples pestañas.

Soy de mente abierta, así que me gustaría saber si algún otro buen desarrollador encuentra SSIS más productivo que simplemente escribir código. Si encuentra SSIS más productivo, dígame por qué.

Uso SSIS todos los días para mantener y administrar un gran almacén de datos y un cubo. He sido 100% inteligencia empresarial y almacenamiento de datos durante dos años. Antes de eso, fui desarrollador de aplicaciones .NET durante 10.

El valor de SSIS es como un motor de flujo de trabajo para mover datos de un lugar a otro con quizás alguna transformación limitada y ramificación condicional en el camino. Si sus paquetes contienen una gran cantidad de secuencias de comandos, entonces su equipo está usando SSIS para las tareas incorrectas o no se siente cómodo con SQL o ha comprado la publicidad. Los paquetes SSIS son muy difíciles de depurar. Los componentes de secuencia de comandos son una pesadilla absoluta y deben usarse solo para formatear, hacer bucles o como último recurso.

1. Mantenga sus paquetes simples, tareas SQL y tareas de flujo de datos.
2. Haga todo el trabajo posible fuera de SSIS, preferiblemente en SQL
3. Mantenga sus variables en un solo alcance global
4. Mantenga su SQL en variables o procedimientos de almacenamiento, nunca en línea
5. Mantenga los valores de sus variables en un almacén de configuración, preferiblemente una base de datos SQL

Intenté usar SSIS varias veces y lo abandoné. En mi opinión, es mucho más fácil hacer todo lo que necesito en C #. SSIS es demasiado complejo, tiene demasiadas trampas y simplemente no vale la pena. Es mucho mejor dedicar más tiempo a mejorar las habilidades de C # que dedicar el mismo tiempo a aprender SSIS; obtendrá mucho más retorno de su entrenamiento.

Además, encontrar y mantener la funcionalidad en una solución VS es mucho más fácil. La prueba unitaria con VS es fácil. Todo lo que necesito hacer es verificar la fuente en Subversion y verificar cómo se cargó. La prueba unitaria de paquetes SSIS es muy complicada, por decirlo suavemente.

Además, hubo situaciones en las que SSIS no pudo completar silenciosamente algunas columnas en algunas filas, simplemente saltándolas sin generar excepciones. Pasamos mucho tiempo solucionando problemas y averiguando qué estaba pasando. Desarrollar una solución alternativa en C # tomó menos de una hora y funciona sin problemas durante dos años.

En mi opinión, SSIS es solo para operaciones ETL y no debe contener lógica fuera de ese alcance.

Tuve la desafortunada experiencia de trabajar en un proyecto en el que pensamos que SSIS sería una solución suficientemente buena para agregar y combinar datos de varias fuentes. Lo desafortunado fue que funcionó muy bien al principio, pero luego los requisitos cambiaron y (eventualmente) nos dimos cuenta de que era la herramienta incorrecta.

tal vez solo lo estábamos usando incorrectamente, pero teníamos muchas dificultades si alguna vez cambiamos nuestro esquema y eventualmente simplemente reutilizamos nuestras definiciones ORM desde la interfaz para escribir una herramienta personalizada en C # para hacer esto. Debido a que ya teníamos el modelo de datos, esto fue sorprendentemente fácil. obviamente, YMMV y yo no somos de ninguna manera un experto en SSIS, pero en este caso SSIS causó muchos trabajos duplicados y dolores de cabeza cuando simplemente arremangarse y codificar a mano fue más fácil de lo esperado.

Así que pensaría mucho en la flexibilidad al considerar SSIS.

SSIS tiene su lugar, y ese lugar no es la programación general o como reemplazo de los procedimientos almacenados. Viene de la escuela ETL (Extraer, Transformar y Cargar) y ahí es donde está su fortaleza.

El nombre antiguo (DTS, Data Transformation Services) y el nuevo nombre (SSIS, Sql Server Integration Services) dejan en claro que es un servicio (o conjunto de servicios) diseñado para manipular datos para integrar la base de datos SQL Server en procesos más grandes.

Si desea mover sus datos mediante programación, es posible que desee mirar Rhino ETL.

También estoy trabajando en mi propio marco, Fluent ETL , ya que SSIS me parece un poco complicado para tareas de datos simples relacionadas con el desarrollo, como cargar datos de prueba unitaria desde un archivo CSV.

SSIS no es un programa. Muchas cosas son más rápidas de hacer en SSIS, y obtienes información muy detallada sobre el progreso y los errores como administrador, lo que puede ser muy bueno en los escenarios que SSIS debe resolver, porque a veces las cosas salen mal y el administrador necesita mucho información.

Habiendo dicho eso, SSIS no es realmente tan útil si no tienes las cosas auto-explicativas - están destinadas a algo, meterse demasiado en la programación general las hace una mierda.