Comparación entre las Extensiones de lenguaje de SQL Server y el CLR de SQL
Se aplica a: 
SQL Server 2019 (15.x) y versiones posteriores
En este artículo se realiza una comparación entre las Extensiones de lenguaje de SQL Server y el Common Language Runtime (CLR) nativo. Se identifican las diferencias clave entre ellos y le ayuda a decidir cuál usar.
Las Extensiones de lenguaje de SQL Server son una característica de SQL Server que se usa para ejecutar código externo. Los datos relacionales se pueden usar en el código externo mediante el uso del marco de extensibilidad.
El Common Language Runtime (CLR) nativo permite implementar algunas de las funcionalidades de SQL Server con lenguajes .NET. El CLR proporciona código administrado con servicios como, por ejemplo, integración entre idiomas, seguridad de acceso del código, administración de la vigencia del objeto y compatibilidad con la depuración y la creación de perfiles.
Los lenguajes disponibles en las Extensiones de lenguaje de SQL Server no reemplazan directamente al CLR de SQL. El marco de extensibilidad y las extensiones de lenguaje amplían el área expuesta de SQL Server y proporcionan un entorno de ejecución para los entornos de ejecución más cercanos al motor de base de datos. También proporcionan un marco de código abierto que se puede usar para incorporar nuevos entornos de ejecución sin cambios en el motor. Actualmente, el área expuesta está restringida al procedimiento almacenado del sistema, sp_execute_external_script.
Estas son algunas de las principales diferencias entre las Extensiones de lenguaje de SQL y el CLR de SQL:
| Característica | SQL CLR | Extensiones de lenguaje de SQL |
|---|---|---|
| Compatibilidad con plataformas | Windows y Linux: Linux solo admite los ensamblados SAFE. |
Windows y Linux: paridad completa en términos de funcionalidad. |
| Modo de ejecución | En proceso | Fuera de proceso |
| Aislamiento | El código de CLR se ejecuta dentro del proceso del motor, y el administrador de la instancia debe confiar en todos los ensamblados o en el código. | El runtime se ejecuta fuera del proceso del motor. Se proporciona aislamiento adicional mediante contenedores de aplicaciones en Windows o espacios de nombres en Linux. La comunicación de red externa también está deshabilitada de forma predeterminada. |
| Sintaxis declarativa (T-SQL) | Tipos definidos por el usuario, agregados definidos por el usuario, funciones, procedimientos y desencadenadores. | Solo ejecución “ad hoc” mediante sp_execute_external_script. |
| Compatibilidad con DDL | CREATE ASSEMBLY para cargar código de usuario y definir otros objetos (funciones, procedimientos, UDT de desencadenadores y UDAggs). |
CREATE EXTERNAL LANGUAGE, EXTERNAL LIBRARY para administrar extensiones y bibliotecas. |
| Compatibilidad con bibliotecas | Se logra mediante ensamblados. | Se pueden usar bibliotecas para runtimes específicos (por ejemplo, paquetes de R o Python y bibliotecas de Java). |
| Runtimes compatibles | .NET Framework | R, Python, Java, C# o Bring Your Own Runtime (BYOR). |
| Marco de OSS | N/A: se puede extender mediante ensamblados .NET definidos por el usuario. | Sí: el SDK de extensión permite crear extensiones o realizar integraciones con runtimes sin cambios en el motor. |
| Integración de QO | Integración a nivel de operador para varias sintaxis, incluido el paralelismo. | Operador de script externo único para enviar o recibir los resultados y los datos de los runtimes; este operador admite la ejecución en modo por lotes y el paralelismo. |
| Gobernanza de recursos | Ninguno: pocos botones fuera del regulador de recursos. | Proporciona el objeto EXTERNAL RESOURCE POOL como un mecanismo independiente para regular los recursos consumidos por los scripts externos o de runtime, y se pueden definir directivas para runtimes externos además de la carga de trabajo de SQL. |
| Nombre del permiso | Control a nivel de instancia mediante objetos con ámbito de base de datos. | Control a nivel de instancia mediante objetos con ámbito de base de datos. |
| Rendimiento | El código del CLR de SQL normalmente supera la extensibilidad debido a la naturaleza de la ejecución. | Ideal para la ejecución orientada a lotes. |
| Funcionalidades de supervisión | DMV sys.dm_clr* y contador de rendimiento limitado del CLR de SQL. |
DMV sys.dm_external*, DMV del grupo de recursos externos y contadores del monitor de rendimiento de JobObject de Windows. |
Cuándo usar cada característica
Sus escenarios y objetivos determinarán si es más conveniente usar las Extensiones de lenguaje o el CLR. Por ejemplo, si necesita ampliar el área expuesta de T-SQL con sus propios agregados o tipos, el CLR es la mejor opción, ya que el tipo o agregado no se pueden definir mediante el mecanismo de extensibilidad. Por otro lado, si desea usar la experiencia de ciencia de datos existente en su organización o equipo, lo más conveniente es usar la integración de R o Python con la extensibilidad.
De forma similar, los objetivos de rendimiento pueden determinar su decisión. Implementar una función regex en C# y usar el CLR es mucho más rápido que usar la extensibilidad para invocar un script de Python que tiene la misma funcionalidad que regex.