DB2 – Sobrecarga de Procedimientos Almacenados.

La sobrecarga de procedimientos es un concepto ampliamente usado en los lenguajes de programación. Ejemplos de ello los podemos encontrar en los constructores que permiten crear un objeto con distintos valores de inicialización. En db2 este concepto de sobrecarga u overloading puede llevarse a los procedimientos almacenados gracias a la cláusula specific.

como aprendimos en el artículo DB2 – Procedimientos almacenados, crear un procedimiento almacenado se rige por la sintaxis básica de Pl/SQL: create procedure name (parameters)  donde name es el nombre calificado de nuestro procedimiento almacenado y de manera única Db2 lo identifica por el valor establecido en specific. Es importante mencionar que de no usarse specific Db2 asignará al procedimiento almacenado un nombre único siguiendo la nomenclatura ‘SQLaammddhhmmssxxx’, este identificador es para uso de Db2 por lo que nosotros podremos llamar a nuestro procedimiento usando el nombre calificado. 

Ejemplos de procedimientos almacenados con y sin especific 

   CREATE PROCEDURE SCHEMA.PROCEDIMIENTO1(PARAM INT);
   SPECIFIC PROCEDIMIENTO1;

 

   CREATE PROCEDURE SCHEMA.PROCEDIMIENTO2(PARAM INT);

 

Como puede observarse, solo usamos specific en procedimiento1 por lo que así será referenciado por db2 tanto en la parte única como la calificada.  La declaración para procedimiento2 por el contrario tendrá dos identificadores: el único establecido de manera automática por db2 y el calificado que es como lo reconoceremos nosotros.

¿Y entonces para que me sirve specific?. Bueno, specific nos permite declarar procedimientos con el mismo nombre pero con un identificador único.  Aquí es precisamente donde entra la sobrecarga de procedimientos almacenados. Y llegamos a la parte interesante. ¿De qué me sirve la sobrecarga?, esa es la pregunta que motiva este artículo. 

Imaginemos el siguiente escenario:

 Hemos diseñado una pantalla muy bonita dónde el usuario podrá consultar el contenido de su tabla de productos filtrándola por proveedor. Para obtener el resultado creamos el siguiente procedimiento almacenado:

CREATE PROCEDURE DAMEPRODUCTOS(PRV_ID INT);

 El usuario muy satisfecho comienza a usar la pantalla pero al poco tiempo decide que quiere filtrar también por marca, entonces tendremos que modificar nuestro procedimiento almacenado para que ahora reciba prv_id y mrc_id 

CREATE PROCEDURE DAMEPRODUCTOS(PRV_ID INT, MRC_ID INT);

 El usuario muy satisfecho con nuestro trabajo, sin saber el trabajo que nos ha dado modificar el SP y la aplicación para considerar las distintitas opciones de filtrado decide que ahora quiere añadir dos filtros más:  Stock Mínimo y  Sin existencia que nos harían agregarle más parámetros a nuestro SP: 

CREATE PROCEDURE DAMEPRODUCTOS(PRV_ID INT, MRC_ID INT; STC_MIN: INT, SINEX INT);

 Uno de los inconvenientes al ir agregando parámetros a nuestro procedimiento almacenado es que de manera interna deberemos ir considerando cada parámetro que llegue nulo para ajustar la consulta que deberemos hacer, agregando con ello complejidad a nuestro procedimiento.  Para simplificar la tarea de mantenimiento podríamos  crear 4 diferentes procedimientos almacenados que se llamen igual pero con distinto identificador. Por ejemplo:

 

CREATE PROCEDURE DAMEPRODUCTOS(PRV_ID INT);
specifc dameprod_1;

 

CREATE PROCEDURE DAMEPRODUCTOS(PRV_ID INT, MRC_ID INT);
specifc dameprod_2;
CREATE PROCEDURE DAMEPRODUCTOS(PRV_ID INT, MRC_ID INT; STC_MIN: INT, SINEX INT);
specifc dameprod_3;

pudiendo hacer las llamadas a cada uno basándonos solo en los parámetros que pasaremos:

call schema.dameproductos(5028);    -- ejecuta dameprod_1

call schema.dameproductos(5028,25);   -- ejecuta dameprod_2

call schema.dameproductos(5028,25,10,0);  -- ejecuta dameprod_3

 Esto del lado de la aplicación nos permite establecer que procedimiento ejecutar en base a los parámetros creados haciéndonos más sencillo el mantenimiento de nuestras aplicaciones y de nuestro procedimientos almacenados.

 Por último algunas consideraciones sobre specific tomadas de Db2 infocenter

 SPECIFIC nombre-específico:

 Proporciona un nombre exclusivo para la instancia del procedimiento que se está definiendo. El nombre específico puede utilizarse al eliminar el procedimiento o realizar un comentario en el procedimiento. No puede utilizarse nunca para invocar el procedimiento. La forma no calificada de nombre-específico es un identificador SQL (cuya longitud máxima es 18). La forma calificada es un nombre-esquema seguido de un punto y un identificador SQL. El nombre (incluido el calificador implícito o explícito) no debe designar otra instancia del procedimiento que exista en el servidor de aplicaciones; de lo contrario se genera un error (SQLSTATE 42710).

 El nombre-específico puede ser igual a un nombre-procedimiento existente.

Si no se especifica ningún calificador, se emplea el que se haya utilizado para el nombre-procedimiento. Si se especifica un calificador, éste deberá ser el mismo que el calificador explícito o implícito del nombre-procedimiento o se generará un error (SQLSTATE 42882).

Si no se especifica el nombre-específico, el gestor de bases de datos genera un nombre exclusivo. El nombre exclusivo será ‘SQL’ seguido de una indicación de fecha y hora expresada en forma de caracteres: ‘SQLaammddhhmmssxxx’.

Sé el primero en comentar

Deja un comentario