Procedimientos almacenados

Un procedimiento almacenado es un programa que se guarda físicamente en una base de

datos. Su implementación varía de un gestor de bases de datos a otro. Este programa está
hecho con un lenguaje propio de cada Gestor de BD y esta compilado, por lo que la
velocidad de ejecución es muy rápida.

Las principales ventajas son:

 El S.G.B.D. es capaz de trabajar más rápido con los datos que cualquier programa
externo, ya que posee acceso directo a los datos a manipular y sólo necesita enviar
el resultado final al usuario.
 Sólo realizamos una conexión al servidor y este ya es capaz de realizar todas las
comprobaciones sin tener que volver a establecer una conexión.
 Podemos reutilizar el procedimiento y este puede ser llamado desde diferentes
aplicaciones y lenguajes. Sólo lo programaremos una vez.

La desventaja principal es que se guarda en la B.D., porque si se corrompe podemos perder

los procedimientos. La solución como siempre en las BB.DD. es tener una buena política
de copias de seguridad.

Trabajar con la sintaxis básica

Existen muchas similitudes entre la sintaxis que se usa para crear procedimientos y
la que se usa para crear funciones. De hecho, estan definidas como un solo
elemento sintáctico en SQL: 2006. Además, la sintaxis es, en su nivel más básico,
similar a como se crean los procedimientos en la mayoría de las implementaciones
SQL.

Utilizar la instrucción CREATE PROCEDURE

La primera sintaxis que veremos es aquella que sirve para crear un procedimiento.
En su nivel más básico, la instrucción CREATE PROCEDURE luce de la siguiente
manera:
CREATE PROCEDURE <nombre del procedimiento>

([<declaración de parámetro>[{, <declaración de parámetro>} …]])

[ <característica de la rutina>… ]

<cuerpo de la rutina>

Como se puede ver, debe proporcionarse un nombre para el nombre para el

procedimiento (en la cláusula CREATE PROCEDURE), seguido por cero o más
declaraciones de parámetro, que van encerradas en paréntesis. Se deben
proporcionar los paréntesis incluso si no se define ninguna declaración. Después de
las declaraciones de parámetro se tiene la opción de definir una o más
características de la rutina.

NOTA

El tipo de características de rutina que se puede definir varía ampliamente entre las
implementaciones SQL, no solamente en términos de cuáles opciones son
soportadas, sino también acerca de cómo están definidas. Consecuentemente, el
análisis sobre estas opciones se mantendrá corto, por lo que deberá asegurarse de
revisar la documentación del producto para mayor información. Por ejemplo, las
extensiones de procedimiento en Oracle están definidas utilizando un lenguaje que
Oracle llama PL/SQL, mientras que en SQL Server y Sybase, las extensiones de
procedimiento son parte de un lenguaje llamado Transact-SQL; ambos lenguajes
son significativamente diferentes del estándar SQL. Por otro lado, MySQL y DB2
generalmente acatan el estándar SQL al definir funciones y procedimientos
almacenados.

Después de haber definido las características del procedimiento, todo está listo para
agregar las instrucciones SQL, que están representadas por el marcador de
posición <cuerpo de la rutina>. Muchas de las instrucciones que se utilizarán en
esta sección serán similares a aquellas que ya se han visto en este libro. Sin
embargo, el estándar SQL/PSM introdujo nuevos elementos del lenguaje que
hicieron más dinámicos los procedimientos.

Invocar procedimientos invocados por SQL

Una vez que se ha creado el procedimiento, puede invocarse (o convocarse)
utilizando una instrucción CALL. La sintaxis básica para la instrucción CALL es la
siguiente:

CALL <nombre del procedimiento>

( [<valor>[ {, <valor> } … ]])

Como se puede ver, debe identificarse el nombre del procedimiento en la cláusula

CALL y seguirla con los valores (en paréntesis) que pasan al procedimiento como
parámetros. Los paréntesis deben utilizarse incluso si ningún parámetro es definido
para el procedimiento. Si más de un parámetro es definido para el procedimiento,
deben separarse por comas. Además, deben seguirse estos lineamientos cuando
se ingresen valores:

 La instrucción CALL deberá incluir el mismo número de valores que el

número de parámetros definidos en el procedimiento.
 Los valores deberán ser ingresados en el mismo orden en que fueron
definidos en el procedimiento.
 Los valores deben ajustarse a los tipos de datos que están asignados a los
parámetros.

Supongamos que se necesitan consultar los datos en las tablas PRODUCTOS y

PROVEEDORES mostrados en las figuras de arriba. Se requiere que los resultados
de la consulta arrojen los nombres de los productos y el número de existencia para
todos los productos del proveedor Jumex.

Para ver esta información, se puede crear una instrucción SELECT que una las dos
tablas, como se muestra en el siguiente ejemplo:

select productos.Nombre,productos.Stock
from productos
inner join proveedores
on productos.idProveedor = proveedores.IDProveedor
and proveedores.Nombre = 'JUMEX';

Desde luego, cada vez que se quiera ver esta información, se tendrá que volver a
crear la instrucción SELECT. Sin embargo, otra opción es almacenar la instrucción
SELECT dentro del esquema. De esta manera, todo lo que se necesita hacer es
convocar la instrucción cada vez que se quiera ver la información de los productos
de Jumex. Una forma de almacenar la instrucción SELECT es dentro de una
definición de vista:

create view JUMEX as

select productos.Nombre,productos.Stock

from productos

inner join proveedores

on productos.idProveedor = proveedores.IDProveedor

and proveedores.Nombre = 'JUMEX';

Una vez que se ha creado la vista, se puede utilizar una instrucción SELECT para
convocar la vista, como se muestra en la siguiente instrucción:

SELECT * FROM JUMEX;

Sin embargo las vistas son muy limitadas respecto a los tipos de instrucción y a la
funcionalidad que soportan. Por ejemplo, no se puede incluir la instrucción UPDATE
en una vista, ni se pueden pasar parámetros desde y/o hacia las vistas. Como
resultado, una mejor forma de almacenar esta instrucción SELECT es como un
procedimiento invocado por SQL. Para hacer esto, se debe crear un objeto de
esquema utilizando la instrucción CREATE PROCEDURE, como se muestra en el
siguiente ejemplo:

DELIMITER //

CREATE PROCEDURE productos_de_jumex()

SELECT PRODUCTOS.NOMBRE, PRODUCTOS.STOCK

FROM PRODUCTOS

INNER JOIN VENDEDORES

ON PRODUCTOS.idProveedor = VENDEDORES.IDProveedor AND

VENDEDORES.NOMBRE = ‘JUMEX’; END //

Esta instrucción representa la cantidad mínima de información que se debe
proporcionar para crear un procedimiento.

Si se quiere convocar el procedimiento que fue creado en el ejemplo anterior, se

puede utilizar la siguiente instrucción:

delimiter ;

CALL productos_de_jumex();

Cuando se ejecuta esta instrucción, se arrojarán los mismos resultados que se

hubieran obtenido si se hubiera ejecutado la instrucción SELECT separadamente,
como se muestra en los siguientes resultados:

Este procedimiento puede ser de mucha utilidad

porque evita que se tenga que crear una
instrucción SQL cada vez que se quiera ver la
información acerca de los productos de Jumex. Sin
embargo para poder arrojar información acerca de
otros tipos de productos de otros proveedores por
ejemplo Lala o Sabritas, se debe crear una nueva
consulta o estructurar un procedimiento para el tipo específico de proveedor. Pero
existe otro alternativa. Se puede crear un procedimiento que no defina
específicamente el tipo de proveedor sino que en su lugar permita al usuario
ingresar el tipo cada vez que quiera provocar ese procedimiento. De esa manera,
solamente se necesita un procedimiento para revisar cualquier tipo deseado de
proveedor.

Para soportar este tipo de procedimiento se debe declarar un parámetro dentro de

la definición del procedimiento que permita al procedimiento aceptar valores de
entrada cuando sea convocado. Regresando a las tablas PRODUCTOS y
PROVEEDORES. Si modificamos el lenguaje del procedimiento que se creo
anteriormente, podemos crear un nuevo procedimiento que incluya el parámetro de
entrada necesario, como se muestra en la siguiente instrucción CREATE
PROCEDURE: