Sé que tendemos a evitar los cursores y bucles dentro de SQL Server a toda costa, pero ¿cuáles son algunas de las situaciones en las que absolutamente necesita consultas de procedimiento, y las consultas basadas en conjuntos simplemente no le darán los resultados?
Entiendo la diferencia entre los dos, simplemente nunca he llegado a una situación en la que necesite usar un cursor. Me pregunto si hay tales situaciones.
Respuestas:
En mis experiencias, me he encontrado con algunas veces cuando se justificaban los enfoques de procedimiento / iterativos.
Si quisiera cambiar programáticamente el tipo de datos de real a decimal en una tabla que tiene 500 columnas mal escritas como esta pregunta SO , un cursor es un buen enfoque ya que el DDL no permite alterar múltiples columnas en una sola declaración.
Si tiene el libro de inmersiones profundas MVP de SQL Server , capítulo 4 "iteración basada en conjuntos: la tercera alternativa" de Hugo Kornelis tiene algunos casos de uso excelentes para operaciones combinadas basadas en cursor / conjunto. Dos de los problemas clásicos a los que hace referencia el autor del capítulo son los totales acumulados y el embalaje de contenedores .
Utilicé el enfoque de iteración basado en conjuntos con buen éxito para un proceso mal diseñado que heredé en el último trabajo. En resumen, hubo un proceso que una vez al año tenía que actualizar 50-75 millones de filas e intentar hacerlo en un solo conjunto volaría nuestros registros. Al agrupar las actualizaciones en lotes más pequeños de N filas, permitió que el registro se mantuviera actualizado y, de hecho, terminó más rápido que el año anterior cuando solo asignaron una tonelada métrica más de espacio en disco.
Cuando algo no se puede hacer basado en conjunto.
Sangrado obvio, por supuesto. Pero tenga en cuenta que hay una diferencia entre "no basado en conjuntos" y las personas que usan una solución de procedimiento porque no entienden los conjuntos o no saben cómo hacerlo con el código basado en conjuntos.
Un ejemplo de código de procedimiento sería enviar un correo electrónico por fila que tenga contenido diferente por fila
Una gran cantidad de código SQL para uso de DBA es de procedimiento. Por ejemplo, bucle (CURSOR o WHILE: sin diferencia) sobre bases de datos y tablas para reconstruir índices y actualizar estadísticas.
Algunas construcciones de SQL permiten el procesamiento fila por fila en el contexto de un conjunto, como CROSS APPLY como este en SO: SELECCIONE LAS 5 filas superiores para cada FK (tenga en cuenta la solución ROW_NUMBER () también)
Editar: extendiendo la respuesta de @ billinkc ...
CROSS APPLY permite operaciones basadas en conjuntos con UDF que tienen una "API de una sola fila"
Sé que está preguntando acerca de SQL Server, pero en el mundo de Oracle (en el pasado), las tablas temporales tenían un costo muy alto, por lo que los procedimientos y desencadenantes basados en el cursor fueron más rápidos y redujeron el "costo" para el servidor. En SQL Server, los cursores solían tener un costo mucho mayor que las tablas temporales, por lo que se desaconsejaba escribir código basado en el cursor. Estoy bastante seguro de que estas discrepancias se han eliminado en la última década.
Para hacer frente a estas situaciones, la mayoría de las personas tienen una regla general para evitar poner lógica empresarial en la base de datos. Si siempre puede hacerlo de manera totalmente absoluta, entonces no habrá ninguna razón para la lógica de procedimiento ni en T-SQL ni en PL / SQL. Las bases de datos relacionales son excelentes en la lógica basada en conjuntos. La mayoría de los lenguajes de programación modernos son excelentes en lógica de procedimiento. Es mejor usar cada uno para lo que son buenos.
Algunos desencadenantes de auditoría con los que he trabajado tenían reglas bastante complicadas para lo que tenía que verificarse y dónde debían actualizarse / registrarse las cosas. Algunos fueron para mantener los sistemas de informes sincronizados con los sistemas transaccionales (no fue mi elección, pero así lo querían). Algunos fueron para un sistema de formulario . Un formulario es una lista de medicamentos, y para cada compañía de seguros, lo que cubrirán / no cubrirán, y si se recetan drug_X, qué reemplazos están cubiertos por el seguro. También era común que las diferentes pólizas grupales de la misma compañía de seguros pagaran por diferentes medicamentos.