¿Se prefieren los procedimientos almacenados CLR a los procedimientos almacenados TSQL en SQL 2005+?

Question

Mi opinión actual es no, prefiero los procedimientos almacenados de Transact SQL porque son una opción más liviana y (posiblemente) de mayor rendimiento, mientras que los procedimientos CLR permiten a los desarrolladores hacer todo tipo de travesuras.

Sin embargo, recientemente he necesitado depurar algunos procesos almacenados TSQL muy mal escritos.Como de costumbre, encontré muchos de los problemas debido a que el desarrollador original no tenía experiencia real en TSQL, estaban enfocados en ASP.NET/C#.

Por lo tanto, el uso de procedimientos CLR proporcionaría, en primer lugar, un conjunto de herramientas mucho más familiar para este tipo de desarrollador y, en segundo lugar, las funciones de depuración y prueba son más potentes (es decir, Visual Studio en lugar de SQL Management Studio).

Me interesaría mucho escuchar tu experiencia ya que parece que no es una elección sencilla.

Answer 1

Hay lugares para T-SQL y CLR bien escritos y pensados.Si alguna función no se llama con frecuencia y requiere procedimientos extendidos en SQL Server 2000, CLR puede ser una opción.También puede resultar atractivo ejecutar elementos como el cálculo justo al lado de los datos.Pero resolver a los malos programadores incorporando nueva tecnología parece una mala idea.

Answer 2

Los procedimientos almacenados CLR no están destinados a reemplazar las consultas basadas en conjuntos.Si necesita consultar la base de datos, aún necesitará incluir SQL en su código CLR, como si estuviera incrustado en un código normal.Esto sería una pérdida de esfuerzo.

Los procedimientos almacenados CLR sirven para dos cosas principales:1) interacción con el sistema operativo, como leer un archivo o colocar un mensaje en MSMQ, y 2) realizar cálculos complejos, especialmente cuando ya tiene el código escrito en un lenguaje .NET para realizar el cálculo.

Answer 3

Alojar CLR en SQL Server tiene como objetivo brindar a los desarrolladores de bases de datos opciones más flexibles en cómo buscaban realizar las tareas.Como otros han mencionado, SQL es excelente para operaciones y modificaciones en conjuntos de datos.Cualquiera que haya realizado un desarrollo extenso de aplicaciones de gran tamaño con reglas comerciales/de dominio complejas probablemente le diría: tratar de hacer cumplir algunas de estas reglas usando SQL puro (a veces en una sola macro consulta) puede volverse una verdadera pesadilla.

Sólo hay ciertas tareas que se manejan mejor de forma procedimental o orientada a objetos.Al tener la opción de utilizar código .NET para desglosar la secuencia lógica, las operaciones de consulta pueden resultar más fáciles de leer y depurar.Habiendo usado procesos almacenados CLR, puedo decirle que pasar paso a paso con el depurador realmente hace que sea más fácil seguir lo que está sucediendo en el nivel de la base de datos.

Solo un ejemplo: aquí utilizamos con frecuencia procesos almacenados CLR como "puerta de entrada" para consultas de búsqueda dinámicas.Digamos una solicitud de búsqueda que puede tener hasta 30 parámetros de búsqueda diferentes.Obviamente, los usuarios no usan los 30, por lo que la estructura de datos pasada tendrá 30 parámetros, pero principalmente DBNULL.El lado del cliente tiene ninguna opción para generar una declaración dinámica, por razones obvias de seguridad.La declaración dinámica resultante se genera internamente sin temor a "extras" externos.

Answer 4

En general, utiliza CLR si tiene algo que no necesita interactuar mucho con la base de datos.Entonces digamos que está analizando o decodificando un valor.Esto es más fácil de hacer en CLR y luego devolver el valor.

Intentar realizar una consulta compelx en CLR simplemente no es el camino a seguir.

Por cierto, esto tampoco cambió en 2008.

Answer 5

Creo que esos dos no son equivalentes...aptos para enfrentarse entre sí.
Se supone que la integración CLR eliminará gradualmente los "procedimientos almacenados extendidos" de antaño. Tenemos algunos de estos en nuestro lugar de trabajo...esencialmente bloques de procesamiento/lógica sobre datos SQL que eran demasiado difíciles/imposibles de realizar mediante procedimientos almacenados de base de datos convencionales/T SQL.Así que lo escribieron como procedimientos almacenados extendidos en archivos DLL de C++ que se pueden invocar de manera similar.Ahora se han eliminado gradualmente y la integración de CLR es el reemplazo.

• Procedimientos almacenados en la base de datos:Si se puede hacer en procesos almacenados de T SQL, hágalo.
• Procedimientos almacenados CLR:si la lógica es demasiado compleja o tediosa para realizarla a través de T SQL...si es algo que requerirá menos líneas de código CLR para abordarlo (manipulación de cadenas, clasificación o filtrado complejo/personalizado, etc.), utilice este enfoque.

Answer 6

Aparte del acceso al sistema de archivos (donde los procesos CLR tienen una ventaja muy pronunciada), usaría procesos T-SQL.Si tiene cálculos especialmente complejos, podría poner esa pieza en un CLR. función y llame a esto desde su proceso (udf es donde descubrí que la integración de CLR realmente brilla).Luego obtendrá los beneficios de la integración CLR para esa parte particular de su tarea, pero mantendrá la mayor cantidad posible de lógica de proceso almacenada en la base de datos.

Answer 7

Dado lo que dijo, preferiría que los desarrolladores estuvieran capacitados adecuadamente en t-SQl y bases de datos en general que permitirles crear posiblemente mucho más daño al rendimiento al permitirles realizar tareas de t-sql en CLR.Los desarrolladores que no entienden las bases de datos usan eso como excusa para evitar hacer las cosas de la mejor manera para el rendimiento de la base de datos porque quieren tomar lo que consideran el camino más fácil.

Answer 8

Siempre todo se reduce a la herramienta adecuada para el trabajo, por lo que realmente depende de lo que esté tratando de lograr.

Sin embargo, como regla general, tiene razón en que los procesos CLR tienen una mayor sobrecarga y nunca funcionarán en operaciones establecidas como T-SQL.Mi pauta es hacerlo todo en T-SQL a menos que lo que necesita se vuelva demasiado complicado en T-SQL.Luego, esfuércese más para que el enfoque T-SQL funcione.:-)

Los procesos CLR son excelentes y tienen su lugar, pero su uso debería ser la excepción, no la regla.

Answer 9

Los libros en línea de SQL Server pagina sobre el tema enumera estos beneficios:

• Un mejor modelo de programación. Los lenguajes .NET Framework son en muchos aspectos más ricos que Transact-SQL y ofrecen construcciones y capacidades que antes no estaban disponibles para los desarrolladores de SQL Server.Los desarrolladores también pueden aprovechar el poder de la biblioteca .NET Framework, que proporciona un amplio conjunto de clases que se pueden utilizar para resolver problemas de programación de manera rápida y eficiente.

• Seguridad y protección mejoradas. El código administrado se ejecuta en un entorno de ejecución de lenguaje común, alojado en el motor de base de datos.SQL Server aprovecha esto para proporcionar una alternativa más segura a los procedimientos almacenados extendidos disponibles en versiones anteriores de SQL Server.

• Capacidad para definir tipos de datos y funciones agregadas. Los tipos definidos por el usuario y los agregados definidos por el usuario son dos nuevos objetos de base de datos administrados que amplían las capacidades de almacenamiento y consulta de SQL Server.

• Desarrollo optimizado a través de un entorno estandarizado. El desarrollo de bases de datos está integrado en futuras versiones del entorno de desarrollo Microsoft Visual Studio .NET.Los desarrolladores utilizan las mismas herramientas para desarrollar y depurar scripts y objetos de bases de datos que utilizan para escribir componentes y servicios de .NET Framework de nivel medio o de cliente.

• Potencial para mejorar el rendimiento y la escalabilidad. En muchas situaciones, los modelos de ejecución y compilación del lenguaje .NET Framework ofrecen un rendimiento mejorado con respecto a Transact-SQL.

Answer 10

Nos encontramos con una situación con una función CLR que se llamaba miles de veces en un proceso SQL normal.Este fue un proceso para importar datos de otro sistema.La función validó los datos y manejó bien los nulos.

Si hicimos la operación en TSQL, el proceso finalizó en unos 15 segundos.Si usamos la función CLR, el proceso finalizó en 20 a 40 minutos.La función CLR parecía más elegante, pero hasta donde pudimos ver, había un éxito de inicio para cada uso de la función CLR.Entonces, si realiza una operación grande usando una función CLR, está bien ya que el tiempo de inicio es pequeño en comparación con el tiempo de la operación.O si llama a la función CLR una cantidad modesta de veces, el tiempo total de inicio para todas las invocaciones de la función sería pequeño.Pero tenga cuidado con los bucles.

Además, para facilitar el mantenimiento, es mejor no tener más idiomas de los que realmente necesitas.

Answer 11

Agregaría un par de razones para usar CLR que quizás no se hayan mencionado.

• Reemplace y amplíe las funciones SQL escalares, de consulta y sin consulta básicas.
  A) Los informes de errores y las alertas se pueden integrar según los requisitos definidos.B) Defina fácilmente los niveles de depuración.C) Habilitar una forma más sencilla de interactuar con servidores SQL externos
• Mueva el código heredado a un entorno administrado.

Answer 12

Publiqué la siguiente respuesta a una pregunta similar: Ventaja de SQL SERVER CLR.Sin embargo, agregaré aquí que C#/VB.net/etc es un lenguaje con el que alguien se siente más cómodo que T-SQL. no ser una razón para usar SQLCLR sobre T-SQL.Si alguien no sabe cómo lograr algo en T-SQL, primero pida ayuda para encontrar una solución T-SQL.Si uno no existe, entonces siga la ruta CLR.

---

La integración SQLCLR/CLR dentro de SQL Server es solo otra herramienta para ayudar a resolver ciertos (no todos) problemas.Hay algunas cosas que hace mejor que lo que se puede hacer en T-SQL puro, y hay algunas cosas que solo se pueden hacer a través de SQLCLR.Escribí un artículo para SQL Server Central, Escalera al nivel 1 de SQLCLR:¿Qué es SQLCLR? (Se requiere registro gratuito para leer los artículos allí), que aborda esta pregunta.Los conceptos básicos son (consulte el artículo vinculado para obtener más detalles):

• Transmisión de funciones con valores de tabla (sTVF)
• SQL dinámico (dentro de Funciones)
• Mejor acceso a recursos externos/Reemplazar xp_cmdshell
  • Pasar datos es más fácil
  • Obtener varias columnas de un resultado retrocedido es más fácil
  • Sin dependencias externas (p. ej.7zip.exe)
  • Mejor seguridad mediante suplantación
• Capacidad para múltiples subprocesos
• Manejo de errores (dentro de Funciones)
• Agregados personalizados
• Tipos personalizados
• Modificar Estado (dentro de una Función y sin OPENQUERY / OPENROWSET)
• Ejecutar un procedimiento almacenado (solo lectura;dentro de una Función y sin OPENQUERY / OPENROWSET)
• Actuación (nota: esto es no es decir en todos los casos, pero definitivamente en algunos casos dependiendo del tipo y complejidad de la operación)
• Puede capturar la salida (es decir,lo que se envía a la pestaña Mensajes en SSMS) (p. ej. PRINT y RAISERROR con un gravedad = 0 a 10) -- Olvidé mencionar este en el artículo ;-).

Otra cosa a considerar es que a veces es beneficioso poder compartir código entre la aplicación y la base de datos para que la base de datos tenga información sobre cierta lógica de negocios sin tener que crear pantallas personalizadas, solo internas, solo para acceder al código de esa aplicación.Por ejemplo, trabajé en un sistema que importaba archivos de datos de clientes y usaba un hash personalizado de la mayoría de los campos y guardaba ese valor en la fila de la base de datos.Esto permitió omitir filas fácilmente al importar sus datos nuevamente, ya que la aplicación codificaría los valores del archivo de entrada y los compararía con el valor hash almacenado en la fila.Si eran iguales, entonces sabíamos instantáneamente que ninguno de los campos había cambiado, así que pasamos a la siguiente fila y era una simple comparación INT.Pero ese algoritmo para hacer el hash solo estaba en el código de la aplicación, por lo que ya sea para depurar el caso de un cliente o buscar formas de descargar parte del procesamiento a los servicios de back-end al marcar filas que tenían al menos un campo con cambios (cambios provenientes de nuestra aplicación). en lugar de buscar cambios dentro de un archivo de importación más nuevo), no había nada que pudiera hacer.Habría sido una gran oportunidad para tener una lógica de negocios bastante simple en la base de datos, incluso si no fuera para el procesamiento normal;tener lo que equivale a un valor codificado en la base de datos sin capacidad para comprender su significado hace que sea mucho más difícil resolver problemas.

Si está interesado en ver algunas de estas capacidades en acción sin tener que escribir ningún código, la versión gratuita de SQL# (del cual soy autor) tiene funciones RegEx, agregados personalizados (UDA), tipos personalizados (UDT), etc.