Procedimientos almacenados (1ª Parte) Composición de un P.A. - Cabecera Una cabecera que define el nombre con el identificaremos a un P.A. Y lo diferenciaremos de otros. Los parámetros de entrada y salida. Opciones de procesamiento del P.A. Procedimientos almacenados Los procedimientos almacenados son objetos de BD que encapsulan colecciones de sentencias SQL transaccionales y que se almacenan para un uso posterior. Podríamos decir que son como las subrutinas y las funciones de otros lenguajes de programación Composición de un P.A. - Cuerpo El siguiente elemento es el cuerpo del P.A. Que contendrá una o mas sentencias SQL que se ejecutarán mas adelante CREATE PROC[EDURE] procedure_name [ {@parameter data_type} [= default] [OUTPUT] ] [,...n] AS sql_statement [...n]
Función de un P.A. Parámetros Uno de los propósitos principales de un procedimiento almacenado es el de devolver una serie de valores de una forma útil. Existen tres formas de devolver un resultado: 1-. Resultset 2-. Parámetros 3-. Valores de retorno Create procedure prgeteqid_2 @Make varchar(50), @Model varchar(50), @EqId int Output as select @EqId = EquipmentId where Make = @Make and Model = @Model Resultset Parámetros Para conseguir una lista de resultados, solo hemos de indicar una sentencia que devuelva una lista de valores (por ejemplo la clausula SELECT) También podemos utilizar la llamada a otro P.A. Que devuelva una lista de valores. Es posible devolver varias listas diferentes de valores. Para ello ejecutamos varios select en este P.A. o llamando a otros P.A. Algunos métodos de acceso a los datos como RDO pueden acceder a todas las listas de resultados que devuelve un P.A. Pero otros solo pueden recibir el primer conjunto o incluso devolver un error Declare @inteqid int Execute prgeteqid_2 'Toshiba', 'Portege 7020CT', @inteqid output Select @inteqid 'Equipment Identifier' Este lote devolverá el parámetro de salidaequipment Identifier -------------------- 1 (1 row(s) affected)
Valores de retorno Create Procedure prgeteqid_3 @Make varchar(50), @Model varchar(50) as Declare @inteqid int Select @inteqid = EquipmentId where Make = @Make and Model = @Model Create Procedure prgeteqid_3 @Make varchar(50), @Model varchar(50) as Return (select EquipmentId where Make = @Make and Model = @Model) Declare @inteqidint Execute@intEqId = prgeteqid_3 'Toshiba', 'Portege7020CT' Select @inteqid'equipment Identifier' Combinación de salidas Declare @inteqid int, @intstatuscode int Execute @intstatuscode = prgeteqid_2 'Toshiba', 'Portege 7020CT', @inteqid output Select @inteqid result, @intstatuscode ErrorCode El resultado de ejecutar este lote de instrucciones seria result ErrorCode ----------- ----------- 1 0 (1 row(s) affected) Combinación de salidas Create Procedure prgeteqid _2 @Make varchar(50), @Model varchar(50), @EqId int output As select @EqId = EquipmentId where Make = @Make and Model = @Model Return @@Error Parámetros opcionales Create Procedure prgeteqid _4 @Make varchar(50) = '%', @Model varchar(50) = '%' as Select * where Make Like @Make and Model Like @Model
Parámetros opcionales Tipos de P.A. Execute prgeteqid_4 'T%', 'Portege% Execute prgeteqid_4 'T%' Paso de parámetros por nombre Definido por el usuario (user-defined) System Extended Temporary Global temporary Remote Execute prgeteqid_4 @Model = 'T%' P.A. Con la opción WITH ENCRYPTION P.A. Definidos por el usuario CREATE PROC[EDURE] procedure_name [; number] [ {@ parameter data_type} [VARYING] [= default] [OUTPUT] ] [,... n] [WITH { RECOMPILE ENCRYPTION RECOMPILE, ENCRYPTION } ] [FOR REPLICATION] AS sql_statement [... n] Los que hemos visto hasta ahora.
P.A. De sistema Son procedimientos almacenados Se almacenan en la B.D. Del sistema (master y msdb) Tienen el prefijo sp_????? (System Procedure) El proceso de compilación y ejecución Parsing El parsing es un proceso durante el cual MS SQL Server comprueba que la sintaxis del comando sea correcta. Si no existe ningún error sistáctico se trocea la sentencia en unidades mas sencillas como las palabras claves, identificadores y operadores Ahora solo queda construir una estructura que describa la serie de pasos necesarios para realizar la operación que el cliente pide. Si el lote contiene una consulta, la estructura interna se llama árbol de consulta y si contiene un procedimiento: árbol de secuencia El proceso de compilación y ejecución Parsing Compilation Execution El proceso de compilación y ejecución Compilación El árbol de secuencia se utiliza para crear un plan de ejecución El módulo de optimización analiza el modo en el que la información puede ser recuperada de las tablas Se busca el modo mas rápido y que menos recursos utiliza. Es dec ir se busca eficiencia en tiempo y recursos. Añade operaciones extras como son la verificación de restricciones, los disparadores, comprobación de la seguridad, etc El resultado es una estructura llamada plan de ejecución TODAVÍA NO HEMOS EJECUTADO NADA
El proceso de compilación y ejecución Ejecución Reutilización de los planes de ejecución El plan de ejecución es almacenado en la cache de procedimiento y AHORA SI, ahora ejecutamos Pueden haber varios pasos en el plan de ejecución que se pueden enviar a diferentes módulos: el gestor de DML, el gestor DDL, el gestor de procedimientos, el gestor de transacciones el gestor de utilidades Los resultados son recogidos en la forma RESULTSET El RESULTSET es enviado al cliente Esta característica es lo que hace de los P.A. la mejor solución que tener almacenadas las consultas de mas uso. La misma consulta ejecutada N veces, requiere del gestor de BD realice los tres pasos de parsing, compilación y ejecución. En los P.A. pasamos directamente al plan de ejecución. Reutilización de los planes de ejecución Autoparametrización Sea la siguiente consulta SELECT FirstName, LastName, Phone, Fax, Email, OrgUnitId, UserName FROM Asset.dbo.Contact where ContactId= 3 Primero el SQL tratará de parametrizar la consulta de la siguiente forma, creando un plan de ejecución SELECT FirstName, LastName, Phone, Fax, Email, OrgUnitId, UserName FROM Asset.dbo.Contact wherecontactid = @P1 Reutilización de los planes de ejecución Los planes de ejecución se dividen en dos partes: El propio código que se ejecutará El contexto El código se puede compartir entre varios usuarios El contexto es propio de cada usuario Las consultas posteriores que coincidan con este plan, reutilizarán el esquema SELECT FirstName, LastName, Phone, Fax, Email, OrgUnitId, UserName FROM Asset.dbo.Contact wherecontactid = 11
Reutilización de los planes de ejecución El plan de ejecución se elimina de la cache por el proceso Lazywriter El P.E. se elimina cuando no ha sido utilizado por un tiempo. ó El P.E. Se elimina cuando ocurre alguna de estas cinco cosas Los datos han cambiado significativamente. Se han creado o eliminado índices. Las restricciones han cambiado o añadido o borrado. La distribución estadística de los índices han cambiado Se llama a sp_recompile Mantenimiento de la integridad de la B.D La tarea más importante de un administrador de base de datos es mantener la integridad de la misma. Si este administrador no es escrupuloso podremos encontrarnos con casos como los siguientes: Canada aparecía con 109 provincias. Una de ellas era Francia La dirección de correo de un cliente era. Hoy hace un día soleado Una misma impresora aparecía escrita de 10 formas distintas LA redundancia, redundancia, redundancia, hay que evitarla. El papel de los P.A. En el desarrollo de aplicaciones de base de datos Mantenimiento de la integridad de la B.D. Reglas complejas Esto es por el uso de aproximaciones procedimientales y no procedimientales Implementación consistentes de reglas de negocio y restricciones, todas ellas, complejas de implementar Diseño modular Mantenimiento Reducción del tráfico de red Ejecución mas rápida Control de la seguridad
Diseño modular Reducción del tráfico de red Los P.A. Permiten a los programadores encapsular las funcionalidades de negocio y facilitan a los usuarios (normalmente otros programas) una interfaz mas fácil. Los P.A. Se comportan como cajas negras. Los usuarios no tienen porque saber como estan implementados, sino qué es lo que hacen, qué parámetros hay que pasarles y qué resultado devuelven. Una de las principales desventajas de una arquitectura de servidor de ficheros o una estructura descentralizada es que existe un gran tráfico de datos entre el servidor y el cliente. Una buena construcción actual de B.D. Implica que el cliente reciba solo aquello que necesita. Los datos intermedios no se pasan. Las personas estan limitadas por la cantidad de información que son capaces de procesar. Los P.A. Facilitan esta labor Mantenimiento Ejecución mas rápida El proceso de diseñar un sistema es cíclico. Los sistemas necesitan ser revisados y mejorados. Ocultando la estructura de la B.D. Los administradores pueden reducir la necesidad de cambiar otros componentes (aplicaciones de clientes, componentes intermedios Los P.A. Tienen varias ventajas de rendimiento respecto a las consultas almacenadas Los P.A. Se almacenan de forma compilada en la cache de P.A. => cuando se necesitan, no tenemos que realizar el parsing y la recompilación. Los P.A. ya estan optimizados
Control de la seguridad Una señal de un sistema de base de datos es que evita que los usuarios accedan directamente a las tablas y fuerzan a utilizar los P.A. Para funciones específicas. Es más fácil gestionar los conjuntos de P.A. Por funcionalidad que gestionar una tabla a nivel de columnas.