Información general de la integración CLR
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. Se hace referencia al código que se ejecuta en CLR 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 información, vea .NET Framework SDK.
Con CLR hospedado en Microsoft 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 a código nativo antes de la ejecución, puede lograr un aumento importante del rendimiento en algunas situaciones.
El código administrado usa Seguridad de acceso del código (CAS) para evitar que los ensamblados realicen ciertas operaciones. SQL Server usa CAS para ayudar a proteger el código administrado y evitar poner en peligro el sistema operativo o el servidor de bases de datos.
Ventajas de la integración CLR
Transact-SQL está diseñado específicamente para el acceso directo a los datos y la manipulación de la base de datos. Aunque Transact-SQL aventaja en el acceso y administración de datos, no es un lenguaje de programación completo. Por ejemplo, Transact-SQL no admite matrices, colecciones, bucles for-each, desplazamiento bit a bit o clases. Aunque algunas de estas construcciones se pueden simular en Transact-SQL, el código administrado ha integrado la compatibilidad 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.
Microsoft Visual Basic .NET y Microsoft Visual C# proporcionan capacidades orientadas a objetos como la encapsulación, la herencia y el polimorfismo. El código relacionado se puede organizar ahora con facilidad en las clases y espacios de nombres. Cuando trabaja con grandes cantidades de código del servidor, esto le permite organizar y mantener más fácilmente el código.
El código administrado es más adecuado que Transact-SQL para los cálculos y la lógica de ejecución complicada y presenta una amplia compatibilidad para muchas tareas complejas, incluidas la administración de cadenas y las expresiones regulares. Con la funcionalidad incluida en la biblioteca de .NET Framework, tiene acceso a miles de clases y rutinas previamente integradas. Se puede tener acceso a éstas con facilidad desde cualquier procedimiento almacenado, desencadenador o función definida por el usuario. La Biblioteca de clases base (BCL) incluye las clases que proporcionan la funcionalidad para la manipulación de cadenas de caracteres, operaciones matemáticas avanzadas, el acceso a archivos, criptografía, etc.
Nota
Mientras muchas de estas clases están disponibles para su uso desde el código CLR en SQL Server, las que no son adecuadas para su uso en el servidor (por ejemplo, las clases de selección de ventana), no están disponibles. Para obtener más información, vea Bibliotecas de .NET Framework admitidas.
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, se comprueba el código para asegurarse de que no se lea ninguna memoria que no se haya escrito previamente. CLR puede ayudar también a asegurarse de 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, vea Rendimiento de la integración CLR.
Elegir entre Transact-SQL y el código administrado
Al escribir procedimientos almacenados, desencadenadores y funciones definidas por el usuario, una decisión que debe tomar es si va a usar el lenguaje Transact-SQL tradicional o un lenguaje .NET Framework como Visual Basic .NET o Visual C#. Use Transact-SQL si el código va a realizar principalmente un acceso a los 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 usar la BCL de .NET Framework.
Elegir entre ejecución en el servidor y ejecución en el cliente
Otro factor a la hora de decidirse sobre si se debe usar Transact-SQL o el código administrado es la ubicación donde desea que resida el código, el equipo servidor o el equipo cliente. Transact-SQL y el 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, quizá prefiera evitar situar las tareas con un consumo de procesador elevado en el servidor de bases de datos. La mayoría de los equipos cliente actuales son muy eficaces y quizá prefiera aprovechar esta capacidad de procesamiento situando cuanto más código sea posible en el cliente. El código administrado se puede ejecutar en un equipo cliente, mientras que Transact-SQL no se puede.
Elegir entre los procedimientos almacenados extendidos y el código administrado
Se pueden crear procedimientos almacenados extendidos para llevar a cabo funcionalidades que no son posibles con los procedimientos almacenados de Transact-SQL. Los procedimientos almacenados extendidos pueden, sin embargo, poner en peligro la integridad del proceso de SQL Server, mientras que el código administrado, cuya seguridad de tipos se comprueba, no puede. Aún más, la administración de memoria, la programación de subprocesos y fibras y los servicios de sincronización se integran más plenamente 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 de escribir los procedimientos almacenados necesarios para realizar las tareas que no son posibles en Transact-SQL. Para obtener más información sobre la integración CLR y los procedimientos almacenados extendidos, vea Rendimiento de la integración CLR.
Vea también