Introducción a la integración de CLR
Se aplica a: 
SQL Server Azure SQL Managed Instance
Common Language Runtime (CLR) es el núcleo de Microsoft .NET Framework y proporciona el entorno de ejecución de todo el código de .NET Framework. El código que se ejecuta dentro de CLR se conoce como código administrado. CLR proporciona varias funciones y servicios necesarios para la ejecución de programas, que incluyen la compilación Just-In-Time (JIT), la asignación y administración de memoria, el forzado de la seguridad de tipos, el control de excepciones, la administración de subprocesos y la seguridad. Para obtener más información, consulte la guía de desarrollo de .NET Framework.
Nota:
Para obtener más información sobre el uso de .NET con extensiones de lenguaje de SQL Server, vea Cómo llamar al entorno de ejecución de .NET en extensiones de lenguaje de SQL Server.
Con CLR hospedado en SQL Server (denominado integración CLR), puede crear procedimientos almacenados, desencadenadores, funciones definidas por el usuario, tipos definidos por el usuario y agregados definidos por el usuario en código administrado. Dado que el código administrado se compila en código nativo antes de la ejecución, puede lograr aumentos significativos del rendimiento en algunos escenarios.
Seguridad de acceso del código
En SQL Server 2016 (13.x) y versiones anteriores, la seguridad de acceso al código (CAS) impedía que los ensamblados realizaran determinadas operaciones.
CLR usa la seguridad de acceso del código (CAS) de .NET Framework, que ya no se admite como un límite de seguridad. Un ensamblado CLR creado con la opción PERMISSION_SET = SAFE puede tener acceso a los recursos externos del sistema, llamar a código no administrado y adquirir privilegios sysadmin. En SQL Server 2017 (14.x) y versiones posteriores, la opción sp_configure, CLR Strict Security, mejora la seguridad de los ensamblados CLR. La opción clr strict security está habilitada de forma predeterminada y trata los ensamblados SAFE y EXTERNAL_ACCESS como si estuvieran marcados con UNSAFE. La opción clr strict security se puede deshabilitar para permitir la compatibilidad con versiones anteriores, pero no se recomienda hacerlo.
Recomendamos que firme todos los ensamblados con un certificado o clave asimétrica con el correspondiente inicio de sesión que tenga concedido el permiso UNSAFE ASSEMBLY en la base de datos master. Los administradores de SQL Server también pueden agregar ensamblados a una lista de los ensamblados en los que el motor de base de datos debe confiar. Para más información, vea sys.sp_add_trusted_assembly.
Ventajas de la integración de CLR
Transact-SQL está diseñado para el acceso directo a los datos y la manipulación en la base de datos. Aunque Transact-SQL destaca en el acceso y la administración de datos, no es un lenguaje de programación completo. Por ejemplo, Transact-SQL no admite matrices, colecciones, bucles for-each, desplazamiento de bits o clases. Aunque algunas de estas construcciones se pueden simular en Transact-SQL, el código administrado tiene compatibilidad integrada con estas construcciones. Dependiendo de la situación, estas características pueden proporcionar una razón de peso para implementar cierta funcionalidad de base de datos en el código administrado.
Visual Basic y C# ofrecen funcionalidades orientadas a objetos, como encapsulación, herencia y polimorfismo. El código relacionado se puede organizar ahora con facilidad en las clases y espacios de nombres. Al trabajar con grandes cantidades de código de servidor, estas funcionalidades le permiten organizar y mantener el código con mayor facilidad.
El código administrado es más adecuado que Transact-SQL para cálculos y lógica de ejecución complicada, y ofrece una amplia compatibilidad con muchas tareas complejas, como el control de cadenas y las expresiones regulares. Con la funcionalidad que se encuentra en la biblioteca de .NET Framework, tiene acceso a miles de clases y rutinas precompiladas. Se puede acceder fácilmente a estas clases desde cualquier procedimiento almacenado, desencadenador o función definida por el usuario. La biblioteca de clases base (BCL) incluye clases que proporcionan funcionalidad para la manipulación de cadenas, operaciones matemáticas avanzadas, acceso a archivos, criptografía, etc.
Nota:
Aunque muchas de estas clases están disponibles para su uso desde el código CLR en SQL Server, las que no son adecuadas para el uso del lado servidor (por ejemplo, clases de ventanas), no están disponibles. Para obtener más información, vea Bibliotecas de .NET Framework compatibles.
Uno de las ventajas del código administrado es la seguridad de tipos o la garantía de que el código tiene acceso a los tipos solo de maneras bien definidas y permitidas. Antes de que se ejecute el código administrado, CLR comprueba que el código es seguro. Por ejemplo, el código se comprueba para asegurarse de que no se lee memoria que no se escribió anteriormente. CLR también puede ayudar a garantizar que el código no manipula la memoria no administrada.
La integración CLR proporciona el potencial para el rendimiento mejorado. Para obtener información, consulte Rendimiento de la arquitectura de integración clR.
Elegir entre Transact-SQL y código administrado
Al escribir procedimientos almacenados, desencadenadores y funciones definidas por el usuario, debe decidir si usar Transact-SQL tradicional o un lenguaje de .NET Framework como Visual Basic o C#. Use Transact-SQL cuando el código realiza principalmente el acceso a datos con poca o ninguna lógica de procedimientos. Use el código administrado para las funciones con uso importante de CPU y procedimientos que presentan una lógica compleja o si desea utilizar la BCL de .NET Framework.
Elegir entre la ejecución en el servidor y la ejecución en el cliente
Otro factor de la decisión sobre si usar Transact-SQL o código administrado es donde desea que resida el código, el equipo servidor o el equipo cliente. Tanto Transact-SQL como código administrado se pueden ejecutar en el servidor. Esto sitúa el código y los datos juntos y le permite aprovechar la capacidad de procesamiento del servidor. Por otro lado, es posible que desee evitar colocar tareas intensivas del procesador en el servidor de bases de datos. La mayoría de los equipos cliente actualmente son eficaces y es posible que desee aprovechar esta potencia de procesamiento colocando tanto código como sea posible en el cliente. El código administrado se puede ejecutar en un equipo cliente, mientras que Transact-SQL no puede.
Elección entre procedimientos almacenados extendidos y código administrado
Los procedimientos almacenados extendidos se pueden crear para realizar funciones que no sean posibles con procedimientos almacenados de Transact-SQL. Sin embargo, los procedimientos almacenados extendidos pueden poner en peligro la integridad del proceso de SQL Server, mientras que el código administrado que se comprueba que es seguro para tipos no puede. Además, la administración de memoria, la programación de subprocesos y fibras, y los servicios de sincronización se integran más profundamente entre el código administrado de CLR y SQL Server. Con la integración clR, tiene una manera más segura que los procedimientos almacenados extendidos para escribir los procedimientos almacenados que necesita para realizar tareas que no son posibles en Transact-SQL. Para obtener más información sobre la integración clR y los procedimientos almacenados extendidos, consulte Rendimiento de la arquitectura de integración clR.