Hay tecnologías en SQL Server que parecen diseñadas por y para gente que odia SQL. Una de ellas es CLR (Common Language Runtime). Si alguna vez has pensado “¿y si meto C# dentro de una base de datos?”, enhorabuena: acabas de invocar al diablo del rendimiento. Pero, como todo en este mundo, si se usa con criterio y sentido común (sí, eso que tan poca gente aplica), puede aportar soluciones que de otro modo serían infernales de implementar en T-SQL.
¿Qué demonios es CLR y por qué está dentro de SQL Server?
CLR es un motor de ejecución de .NET. Desde SQL Server 2005 tenemos la opción de crear procedimientos almacenados, funciones, triggers y tipos definidos por el usuario usando lenguajes .NET como C# o VB.NET. Esto permite extender la funcionalidad de T-SQL cuando éste se queda corto. Y sí, hay que reconocerlo, T-SQL se queda corto en ciertas áreas, como el procesamiento intensivo de texto, operaciones matemáticas complejas o manipulación avanzada de estructuras de datos.
Ahora bien, que algo se pueda hacer no significa que deba hacerse. De hecho, habilitar CLR en una instancia es como abrir una puerta lateral en un castillo: puede estar bien si sabes quién entra y sale, pero si la dejas abierta, prepárate para las sorpresas.
Activar CLR: el primer pecado
Por defecto, CLR viene deshabilitado. Hay que habilitarlo explícitamente:
EXEC sp_configure 'clr enabled', 1;
RECONFIGURE;Hasta aquí todo bien. Pero luego llega la decisión importante: ¿qué nivel de seguridad vamos a aplicar? Aquí es donde muchos pecan por ignorancia o por prisa. SQL Server permite establecer niveles de seguridad en los ensamblados: SAFE, EXTERNAL_ACCESS y UNSAFE.
- SAFE es la opción por defecto y la más limitada. Permite usar solo código seguro dentro del sandbox de SQL Server. Vamos, que no puedes acceder al sistema de archivos ni hacer llamadas a red.
- EXTERNAL_ACCESS permite acceso al sistema, como archivos o recursos de red. Requiere permisos adicionales en la base de datos y en el servidor.
- UNSAFE es exactamente lo que parece: la carta blanca para que alguien con tiempo libre y ganas de destruir te monte un agujero de seguridad monumental. Desde abrir un puerto TCP hasta modificar binarios en disco. Y si el servidor ejecuta SQL Server con permisos de sistema, el daño potencial es ilimitado.
El resumen es simple: si usas EXTERNAL_ACCESS o UNSAFE y no sabes exactamente lo que estás haciendo, ya puedes ir llamando al responsable de seguridad para una charla “interesante”.
¿Y por qué usar CLR? ¿Realmente aporta algo?
En ocasiones, sí. Hay escenarios donde CLR no solo tiene sentido, sino que puede ser la solución óptima. Por ejemplo:
- Procesamiento de texto complejo: Las expresiones regulares en T-SQL son una promesa aún. Mientras que estamos empezando a verlas en las previews de Azure SQL y SQL Server 2025, en C# puedes usarlas sin volverte loco. Una función CLR que use Regex.Match puede reemplazar cientos de líneas de T-SQL feo y lento.
- Cálculos matemáticos avanzados: ¿Has intentado hacer operaciones trigonométricas complejas o cálculos estadísticos avanzados con T-SQL? No, ¿verdad? Pues eso. CLR te permite usar librerías de .NET que hacen esto sin romperte la cabeza. Aunque, pensándolo bien, ¿no preferirías usar python o R para estas cosas?
- Manejo de estructuras como arrays o diccionarios: Aunque con SQL Server 2022 y sus mejoras en JSON y XML estas necesidades han bajado, aún hay casos donde un buen Dictionary<string, List<int>> en C# resuelve en milisegundos lo que en T-SQL requeriría un máster.
- Performance en funciones escalares: Una función escalar en T-SQL puede ser un veneno para el rendimiento si se ejecuta por cada fila de una tabla grande. En CLR, ese impacto puede reducirse significativamente.
Eso sí, si el único motivo para usar CLR es que “yo sé C# y no me gusta T-SQL”, lo que necesitas no es un CLR, es un cambio de trabajo.
Cómo crear un ensamblado CLR sin invocar a Satán
Veamos el proceso básico:
Primero escribes el código en C# (en Visual Studio o lo que uses). Luego compilas el ensamblado (DLL) y lo subes a SQL Server con CREATE ASSEMBLY. Por último creas la función o procedimiento que lo expone. Un ejemplo sencillo:
Código C#:
using System;
using System.Data.SqlTypes;
using Microsoft.SqlServer.Server;
public class Utilidades
{
[SqlFunction]
public static SqlString ReverseString(SqlString input)
{
char[] array = input.Value.ToCharArray();
Array.Reverse(array);
return new string(array);
}
}Compilas esto como DLL y lo subes:
CREATE ASSEMBLY Utilidades
FROM 'C:\CLR\Utilidades.dll'
WITH PERMISSION_SET = SAFE;
CREATE FUNCTION ReverseString(@input NVARCHAR(MAX))
RETURNS NVARCHAR(MAX)
AS EXTERNAL NAME Utilidades.[Utilidades].ReverseString;Y voilà. Ya puedes usar dbo.ReverseString(‘hola’).
¿Dónde rompe CLR las cosas y por qué?
Ahora hablemos de los pecados originales del CLR. El primero es la dificultad de mantenimiento. El código está fuera del ámbito natural del DBA. Si mañana hay que parchear un bug en ese ensamblado, necesitas recompilar, volver a subirlo y cruzar los dedos para que no tengas dependencias rotas. Además, muchas veces ni siquiera se versionan correctamente. Y sí, lo hemos visto en producción. Más veces de las que nos gustaría.
Segundo, el tema de la seguridad. Un ensamblado con UNSAFE puede hacer cualquier cosa en el sistema operativo. Y cuando decimos cualquier cosa, es cualquier cosa. ¿Quieres que tu base de datos escanee el disco C:? Puedes hacerlo. ¿Deberías hacerlo? No. Nunca.
Tercero, el rendimiento. Aunque en algunos escenarios el CLR escala mejor que T-SQL (especialmente en funciones escalares y algoritmos complejos), introducir CLR sin medir su impacto real es como poner un turbo a un coche sin frenos. Necesitas pruebas serias, monitorización con Extended Events o Profiler, y entender bien los contextos de ejecución y memoria.
CLR y los entornos modernos
¿Sigue teniendo sentido usar CLR en 2025? Depende. SQL Server ha mejorado mucho en áreas como funciones en línea, JSON, XML, y hasta integración con Python y R vía Machine Learning Services. Muchas cosas que antes requerían CLR ahora se pueden hacer dentro del propio SQL Server sin salir del ecosistema T-SQL.
Pero aún hay casos de uso válidos: si necesitas lógica reutilizable, validaciones complejas, o consumir recursos externos con control, puede ser una herramienta útil. Eso sí, no abuses. Lo que empieza como una solución elegante puede acabar como un infierno de dependencias, DLLs perdidas y bugs imposibles de depurar.
Conclusión
El CLR no es el enemigo. El enemigo es usar herramientas que no entendemos solo porque «molan» o porque «así lo hacemos en .NET». SQL Server permite muchas cosas, pero no todas son recomendables. Si vas a meter CLR en tu arquitectura, hazlo con cabeza, documentación, versiones bien gestionadas y, por supuesto, tests.
Y si estás usando funciones CLR porque no sabías cómo hacerlo en T-SQL… mejor sigue leyendo el blog. Tenemos artículos sobre expresiones regulares y otras maravillas menos propensas a prenderle fuego a tu entorno productivo.
Porque sí, puedes meter C# en SQL Server, y también puedes meter un gato en una lavadora. Pero no deberías.
Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
