Procedimiento almacenado frente a SQL incorporado en el rendimiento de SSIS

Question

Recientemente completé un curso de SSIS.

Una de las mejores prácticas que obtuve fue utilizar SIEMPRE los procedimientos almacenados en tareas de flujo de datos en SSIS.

Supongo que hay un argumento en torno a la seguridad, sin embargo, el tutor dijo que como los procedimientos almacenados realizaban todo el trabajo "nativo" en el servidor SQL, hubo/hay un impulso de rendimiento significativo.

¿Hay algo de cierto en esto o en los artículos que debaten este punto?

Gracias

Answer 1

Recuerde - en su mayoría cursos se llevan a cabo por personas despistados porque las personas con conocimientos ganan dinero haciendo consultoría, que paga mucho mejor que el entrenamiento. La mayoría de los entrenadores viven en una casa de vidrio que nunca pasa 9 meses trabajando en un almacén de datos de 21tb;)

Esto está mal. Punto.

que sólo tiene sentido cuando la instrucción SQL no tira de datos fuera de la base de datos - por ejemplo, la fusión de mesas, etc.

lo contrario, es una cuestión de lo inteligente que configura el lado de SSIS. SSIS puede escribir datos que no usan SQL, utilizando mecanismos de copia masiva. SSIS es mucho más flexible, y si extrae datos de una base de datos remota, entonces el argumento de no abandonar la base de datos (es decir, el procesamiento nativo) es un punto estúpido. Cuando copio datos de SQL Server A a SQL Server B, un SP en B no puede procesar los datos de A nativo.

En general, es más rápido cuando toma los datos DE A y los empuja a A y todo el procesamiento puede hacerse en un SP simple, que es un caso de borde degenerado (es decir, uno simplista).

La ventaja de SSIS es la flexibilidad del procesamiento de datos en un entorno diseñado para el flujo de datos, que en muchos casos es necesario en el proyecto y hacerlo en procedimientos almacenados podría convertirse en una pesadilla.

Answer 2

Tema antiguo, pero un tema pertinente.

Para una conexión de fuente de datos, prefiero los SP a las consultas integradas cuando A) la lógica es lo suficientemente simple para ser manejada de ambas maneras, y B) el soporte del SP es más fácil que trabajar con el paquete. No he encontrado mucha, si la hay, diferencia en el rendimiento para la fuente de datos si el SP devuelve un conjunto de resultados bastante directo.

Nuestra tienda tiene un proceso de implementación más complicado para los paquetes, lo que hace que los SP sean una fuente preferida.

No he encontrado muchas aplicaciones para que un SP sea un destino de datos, excepto tal vez una llamada SP de registro ocasional.