Muchos de los problemas que requieren desnormalización y/o operaciones secuenciales pueden ser manejados excepcionalmente bien por el CLR y se pueden utilizar para mejorar drásticamente el rendimiento sin sacrificar la facilidad de uso en el extremo de SQL (mucho). En lugar de confiar por completo en operaciones iterativas o basadas en conjuntos, puede adoptar un enfoque híbrido, utilizar una solución basada en conjuntos para los grandes traslados y cambiar a un modelo iterativo para los bucles ajustados.
Los tipos incorporados hierarchyid y geoespaciales (es decir, geography) en SQL Server 2008 son buenos ejemplos del problema de desnormalización. Ambos contienen una cantidad (casi) arbitrariamente grande de datos que son difíciles de normalizar sin perjudicar el rendimiento. Tendría que usar recursion o cursores para hacer un trabajo significativo con ellos de lo contrario, o usar un nido de desencadenantes y/o tareas programadas para mantener una tabla de desnormalización
Otro problema que he resuelto con los tipos de CLR es la compresión en línea. Esto puede sonar como un ejercicio sin sentido o académico, pero cuando sus datos completamente normalizados están presionando en los terabytes, una reducción del 80-90% en el tamaño significa mucho. SQL tiene su propia compresión incorporada ahora y SQL 2005 tenía vardecimal, y esas son también buenas herramientas, pero un algoritmo de "minimización" de dominio puede ser varias veces más eficiente en términos de carga de CPU y tasa de compresión. Obviamente, esto no se aplica a todos los problemas, pero se aplica a algunos.
Otro problema muy común que a menudo se encuentra en este sitio es generar una secuencia sobre la marcha, por ejemplo, una secuencia de fechas consecutivas.Las soluciones comunes son los CTE recursivos, las tablas de secuencias estáticas y las poco conocidas tablas spt_values, pero un CLR UDF simple funciona mejor que cualquiera de ellos y ofrece mucha más flexibilidad.
Último en mi lista: los agregados de transmisión definidos por el usuario también son muy útiles, especialmente para cualquier cosa relacionada con las estadísticas. Hay algunas cosas que simplemente no puede componer a partir de los agregados de SQL incorporados, como medianas, promedios móviles ponderados, etc. Los ADU también pueden tomar múltiples argumentos para que pueda parametrizarlos; técnicamente no se garantiza que un agregado reciba datos en un orden particular en la versión actual de SQL Server, pero puede evitar esa limitación al alimentarlo con un ROW_NUMBER como argumento adicional y usarlo para implementar casi cualquier función de ventana (tener el agregado escupe un UDT que luego puede transformarse en una tabla).
En realidad, es muy frustrante la poca cantidad de ejemplos de aplicaciones verdaderamente útiles de SQL-CLR; busca en Google y obtienes 10 millones de resultados, cada uno de ellos por alguna concatenación de cadenas tontas o expresiones regulares. Estos son útiles, pero tómese unos minutos para aprender sobre los UDT y los UDA SQL en particular, y comenzará a ver muchos usos para ellos en sus propias aplicaciones. No se vuelvan locos, por supuesto, piensen cuidadosamente si existe o no una mejor solución en SQL puro, pero tampoco los descarten.
Esta es una de las publicaciones más informativas que he leído en mi vida. Gracias. –
+1 muy bien puso –