SQLServer 2005 Administrado

En esta entrada hablaremos un poco acerca de la inclusión del CLR dentro de SQL Server 2005, y cómo esto nos permite exponer elementos administrados dentro del motor. Por ejemplo, procedimientos almacenados, funciones, triggers, UDTs(tipos definidos por el usuario), entre otros, escritos en un lenguaje administrado por el CLR (C#, VB.NET) y desplegados como objetos de la base de datos, pero administrados por el CLR para su ejecución, como cualquier ensamblado que se crea después de su compilación.

Para crear un proyecto desde Visual Studio .NET 2005 para SQL Server, se escoge la opción SQL Server Project:



Esta template, nos permite un proyecto de SQL Server, desde el cual podremos adicionar los siguientes items:

Seleccionando cualquiera de los items anteriores, visual studio crea por nosotros la clase en la cual podemos adicionar el método, que finalmente será desplegado dentro del motor como un objeto de la base de datos que puede ejecutarse como cualquiera de sus contrapartes escritos en Transact SQL.

Por ejemplo, veamos lo que sería un método administrado que SQL Server 2005 entiende como un procedimiento almacenado, con los elementos necesarios para que funcione como tal:

using (SqlConnection conexion = new SqlConnection("context connection = true"))
{
SqlCommand comando = new SqlCommand();
comando.CommandText = "SELECT LastName" + Convert.ToChar("+").ToString() + "' '" +
Convert.ToChar("+").ToString() + "FirstName, Title, BirthDate, Address, City " +
"FROM dbo.Employees";
comando.Connection = conexion;
conexion.Open();
SqlContext.Pipe.ExecuteAndSend(comando);
}

Es una consulta muy sencilla, donde se pueden evidenciar algunos elementos de importancia como son:

1. Al constructor de la clase SqlConnection ahora le pasamos el valor "context connection = true" que está indicando que nuestro código se va a ejecutar dentro del contexto de SQL Server, administrado por el CLR. Esto significa que no van a ejecutarse todos los mecánismos de conexión utilizados por SQLConnection a través del SQLDataProvider.

2. El método Send de la propiedad Pipe es equivalente a un PRINT en Transact SQL. La propiedad Pipe es de tipo SQLPipe, y permite insertar información en la corriente de salida utilizando para esto el protocolo TDS(Tabular Data String), con el cual SQL Server habla con un cliente. TDS permite poner ResultSets y Mensajes en el camino.

Bien este método entonces será desplegado como un procedimiento almacenado dentro del motor. Y el despliegue? sencillo, simplemente ejecutar el proyecto y con esto ya tenemos desplegado nuestro procedimiento almacenado administrado como un objeto del motor. Hay comandos propios de Transact SQL que se pueden también ejecutar desde SQL Server 2005, pero eso es tema para otra entrada. Es importante que antes de ejecutar cualquiera de estos comandos, el CLR debe estar activado dentro de SQL Server, ya que por seguridad viene deshabilitado por defecto.

Desde visual studio .NET podemos hacer uso del Server Explorer para ir viendo lo que está ocurriendo con nuestros elementos administrados dentro del motor, ahi en diferentes carpetas podemos desplegar la de "Stored Procedures" y entonces el procedimiento almacenado tendrá el nombre que le hayamos dado al método escrito en C#. Otra carpeta que se encuentra es Assemblies, en la cual queda desplegado el ensamblado el cual toma por defecto el nombre de nuestro proyecto.

En conclusión, con SQL Server - CLR, tenemos muchas ventajas como por ejemplo: poder extender la funcionalidad del motor, porque podemos escribir nuestra lógica utilizando lenguajes de alto nivel y no Transact SQL. Aunque SQL Server no sea un motor orientado a objetos, estas características le añaden orientación a objetos de cierto modo, pero debemos tener cuidado, ya que ciertas características de la POO, no pueden ser entendidas dentro del SQL Server 2005. Es muy importante saber que no puedo tomar todos mis objetos escritos en Transact-SQL y cambiarlos por objetos administrados, esto no es solución de ninguna manera. La idea de tener hospedado el CLR dentro de SQL Server, es para escribir cierta clase de objetos que con transact SQL pueden llegar a ser demasiado complejos y no tener el mismo desempeño que escritos con lengaujes administrados. Por ejemplo, funciones matemáticas, operaciones de encripción y desencripción, todo lo referente al trabajo con cadenas (lo cual tiene un desempeño pobre con Transact SQL), operaciones como envio de coreo electrónico. Pero entonces nunca podremos suplir el gran desempeño que Transact ofrece para lo que tiene que ver con operaciones de tipo conjunto, es decir consultas sobre la información almacenada dentro de nuestra base de datos, en este contexto, los objetos escritos con lenguajes administrados, van a arrojar un desempeño mucho menor que los de transact. y finalmente cabe resaltar la depuración sobre obejetos escritos en Transact SQL desde el entrono de Visual Studio .NET, con lo cual tengo un elemnto más a favor para poder verificar que está ocurriendo con la jecución de mis elementos no administrados.