[SQL]Procedimientos almacenados paso a paso
Un procedimiento almacenado (store procedure) no es más que una secuencia ordenada de instrucciones T-SQL, que pueden recibir y proporcionar parámetros provistos por el usuario y se pueden guardar en el servidor con un nombre, para posteriormente se invocados y ejecutados, por lo regular desde una aplicación (Escritorio o Web). Desde la versión 2005, se incorpora la posibilidad de utilizar procedimientos almacenados usando el CLR de .NET. Es decir tenemos dos tipos de procedimientos almacenados.
Un procedimiento almacendado CLR es una referencia a un método de un ensamble (dll) de .NET Framework que puede aceptar y devolver parámetros suministrados por el usuario.
Ventajas de usar SP
- Compilación: La primera vez que se invoca un SP, el motor lo compila y a partir de ahí, se sigue usando la versión compilada del mismo, hasta que se modifique o se reinicie el servicio de SQL. Esto siginifica que se tendrá un mejor rendimiento que las consultas directas que usan cadenas con las instrucciones T-SQL, que se compilan cada vez que se invocan.
- Automatización: si tenemos un conjunto de instrucciones T-SQL, las cuales queremos ejecutar de manera ordenada, un SP es la mejor manera de hacerlo.
- Administración: cuando realizamos aplicaciones con un gran numero de lineas de código, y queremos hacer cambios, solo implica modificar un SP y no toda la aplicación, lo que significa solo cambiamos los SP en el servidor y no tenemos que actualizar la aplicación en todos los equipos cliente.
- Seguridad: una parte importante es que a los usuarios de nuestra aplicación, solo les proporcionamos los permisos para ejecutar los procedimientos almacenados y no el acceso a todos los objetos de la base. Es decir, si en nuestra aplicación encuentran una vulnerabilidad como SLQ Injection no se podrá explotar ejecutando SQL directamente.
- Programabilidad: Los SP admiten el uso de variables y estructuras de control como IF, Bucles, Case, etc. además del manejo de transacción y permite controlar excepciones. Y cuando trabajamos con SP CLR podemos hacer uso de cualquier lenguaje .NET como lo son C# y VB.NET.
- Trafico de Red: Pueden reducir el trafico de la red, debido a que se trabaja sobre el motor (en el servidor), y si una operación incluye hacer un trabajo de lectura primero y en base a eso realizar algunas operaciones, esos datos que se obtienen no viajan por la red.
Creando un Procedimiento almacenado
Para crear un procedimiento almacenado solo basta con ir a la base de datos desplegar el árbol hasta la parte de programación y luego en procedimientos almacenados y damos clic derecho en nuevo procedimiento almacenado como se ve en la siguiente figura:
Lo cual genera el siguiente código:
SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO -- ============================================= -- Author: <Author,,Name> -- Create date: <Create Date,,> -- Description: <Description,,> -- ============================================= CREATE PROCEDURE <Procedure_Name, sysname, ProcedureName> -- Add the parameters for the stored procedure here <@Param1, sysname, @p1> <Datatype_For_Param1, , int> = <Default_Value_For_Param1, , 0>, <@Param2, sysname, @p2> <Datatype_For_Param2, , int> = <Default_Value_For_Param2, , 0> AS BEGIN -- SET NOCOUNT ON added to prevent extra result sets from -- interfering with SELECT statements. SET NOCOUNT ON; -- Insert statements for procedure here SELECT <@Param1, sysname, @p1>, <@Param2, sysname, @p2> END GO
Es aquí en donde editamos nuestro procedimiento como mejor nos interese, en este caso usando la base de datos Northwind, crearemos un SP sencillo que queda más o menos así:
USE [Northwind] GO CREATE PROCEDURE [dbo].[GetAllEmployees] -- Add the parameters for the stored procedure here @LastName nvarchar(50), @FirstName nvarchar(50) AS BEGIN -- SET NOCOUNT ON added to prevent extra result sets from -- interfering with SELECT statements. SET NOCOUNT ON; -- Insert statements for procedure here SELECT LastName, FirstName, Title FROM dbo.Employees WHERE FirstName = @FirstName AND LastName = @LastName END
En este sencillo ejemplo, sólo devuelve el empleado especificado (nombre y apellidos), y el titulo a partir de una vista. Este procedimiento almacenado acepta coincidencias exactas de los parámetros pasados.
Para ejecutar el código debemos hacerlo de esta manera:
EXEC dbo.GetAllEmployees 'Davolio', 'Nancy'
Cómo lo consumimos desde una aplicación en .NET, pues de esta manera:
static void Main(string[] args) { //Creamos una nueva conexion. SqlConnection miConn = new SqlConnection("Data Source=NORTABLEPC\\SQLEXPRESS;Initial Catalog=Northwind;Integrated Security=True"); //Creamos un nuevo comando SqlCommand miComm = new SqlCommand(); //Le asignamos la conexion. miComm.Connection = miConn; //especificamos que el comando es un stored procedure miComm.CommandType = System.Data.CommandType.StoredProcedure; //y escribimos el nombre del stored procedure a invocar miComm.CommandText = "dbo.GetAllEmployees"; //Creamos un nuevo parametro SqlParameter paramLastName = new SqlParameter(); paramLastName.ParameterName = "@LastName"; paramLastName.SqlDbType = System.Data.SqlDbType.NVarChar; paramLastName.Value = "Davolio"; miComm.Parameters.Add(paramLastName); SqlParameter paramFirstName = new SqlParameter(); paramFirstName.ParameterName = "@FirstName"; paramFirstName.SqlDbType = SqlDbType.NVarChar; paramFirstName.Value = "Nancy"; miComm.Parameters.Add(paramFirstName); //Y los agregamos a la coleccion de parametros del comando myComm.Parameters.Add(myParam) 'Creamos un nuevo DataAdapter con nuestro comando. SqlDataAdapter miDA = new SqlDataAdapter(miComm); //Creamos un dataset para soportar los datos devueltos por el stored procedure DataSet EmpleadosDS = new DataSet(); //Pedimos al Data Adapter que llene el dataset (Esto llama a nuestro comando) miDA.Fill(EmpleadosDS); //Y lo mostramos por pantalla foreach (DataRow row in EmpleadosDS.Tables[0].Rows) { Console.WriteLine(row["LastName"].ToString() + " " + row[1].ToString() + " " + row[2].ToString()); } }
Procedimientos Almacenados con CLR
En Common Language Runtime (CLR), los procedimientos almacenados se implementan como métodos estáticos públicos en una clase de un ensamblado de Microsoft .NET Framework. El método estático se puede declarar como void o puede devolver un valor entero. Si devuelve un valor entero, éste se trata como el código devuelto desde el procedimiento. Los parámetros que se pasan a un procedimiento almacenado CLR pueden ser cualquiera de los tipos nativos de SQL Server que tengan un equivalente en código administrado. Para que la sintaxis Transact-SQL cree el procedimiento, estos tipos se deben especificar con el equivalente del tipo nativo de SQL más adecuado.
Ejemplo:
Para crear un SP con integración del CLR vamos a usar VS, y creamos un Proyecto de tipo SQL, al que llame StoreProcedure_Demo, lo primero que hace Visual Studio es preguntar el origen de datos, como se ve en la figura siguiente:
En donde seleccionamos Microsoft SQL Server (SqlClient) y damos clic en continuar. Ahora toca el turno de elegir el Servidor
En donde yo selecciono el servidor NORTABLEPC\SQLEXPRESS, y la base de datos Northwind, luego verifico la conexión y si todo va bien, por ultimo nos pedirá que si queremos habilitar la integración con el CLR, damos clic y listo. Luego damos clic derecho en nuestro proyecto Agregar->Procedimiento almacenado, como se ve en la figura:
Al procedimiento lo llamamos: GetEmpleado, damos y damos clic en Aceptar. Ahora vamos a escribir el siguiente código:
using System; using System.Data; using System.Data.SqlClient; using System.Data.SqlTypes; using Microsoft.SqlServer.Server; public partial class StoredProcedures { [Microsoft.SqlServer.Server.SqlProcedure (Name="GetEmpleado")] public static void GetEmpleado() { // Inserte el código aquí SqlContext.Pipe.Send("Hola Mundo! son las : " + System.DateTime.Now.ToString() + "\n"); using (SqlConnection connection = new SqlConnection("context connection=true")) { connection.Open(); SqlCommand command = new SqlCommand("SELECT LastName, FirstName FROM Employees", connection); SqlDataReader reader = command.ExecuteReader(); SqlContext.Pipe.Send(reader); } } };
En el código anterior solo mandamos un mensaje, y devolvemos un select sencillo de los empleados, Bien para que esto funcione, debemos generar una solución de nuestro proyecto y después una implementación del mismo, esto permite que automáticamente se envié la dll a nuestra base de datos con el nombre de nuestro proyecto, y al mismo tiempo agrega el procedimiento llamado GetEmpledo
Ahora solo nos resta ejecutar nuestro procedimiento con la siguiente instrucción:
EXEC dbo.GetEmpleado
Lo interesante de esto, es que una vez que ya hemos llamado al SP, cuando se ejecute de nuevo, ya no se compilara instrucción por instrucción solo se llama al dll y listo, el resultado de ejecutarlo es el siguiente, por un lado manda el resultado y por otro el mensaje de “hola mundo” con la hora de la maquina, como se ve en la figura:
Hasta aquí dejamos este post, ya veremos en otro como ejecutar dichos procedimientos almacenados desde una aplicación. Espero que les sea de utilidad este post y recuerden si lo creen conveniente tomen 5 min, para votar por este blog en la siguiente página : http://www.blogit.ms/ , voten por http://mspnor.wordpress.com
Saludos!!!
, y quieres saber que es lo que te perdiste, gracias a channel 9 podemos ver las conferencias de lo que se va presentado día con día, y esta ves se trata de “The Future of C#” en la que Anders Hejlsberg Él es el jefe de diseño de C # y participante clave en el desarrollo de la de Microsoft. NET Framework. Desde su lanzamiento inicial en 2000 nos habla de las nuevas características de la versión 4.0 de C#.
, y esto por todo lo que les ofrecerá tanto a usuarios como a desarrolladores.
Me ha parecido muy interesante y divertido el post de 
Y hasta aquí la lista de Kevin en su post, ni que decir tiene que comparto sus reflexiones en la mayoría de los puntos. Por mi parte, añadiría los siguientes agentes irritantes que conozco por experiencia propia o de conocidos:
, que son aquellos que van cambiando conforme el desarrollo avanza y que obligan a realizar refactorizaciones, descartar código escrito, e introducir peligrosas modificaciones, afectando a veces por debajo de la línea de flotación del software. Más rabia produce, además, cuando se atribuyen una mala interpretación por parte del desarrollador de una especificación imprecisa.
Comentarios recientes