El procesamiento de datos es una de las actividades ms arduas a la que nos enfrentamos al desarrollar

sistemas transaccionales, especialmente cuando se afectan grandes cantidades de datos. Por medio de
procedimientos almacenados, o stored procedures (SP), el sistema de base de datos es capaz de ejecutar un
conjunto de instrucciones bien coordinadas entre s que afectan la informacin con el fin de lograr un objetivo
dentro del sistema.
A continuacin comparto algunas tcnicas que pueden ser tiles para crear stored procedures confiables con
una gran cantidad de instrucciones y gestionar los grandes bloques de informacin que se ven afectados por
estos. Vale la pena mencionar que aunque este artculo utiliza como referencia las capacidades disponibles
en SQL Server, la teora bsica y la mayora de la sintxis es aplicable a otros manejadores de base de datos.
Catlogo de procedimientos
La primera recomendacin es tener un catlogo de stored procedures que nos ayude a tener un listado de los
procedimientos con los que contamos. En su forma mnima, esta tabla simplemente tendra Id y nombre del
proceso, pero puede extenderse para incluir otra informacin relevante, tal como desarrollador o fecha de
actualizacin.
IdProceso Proceso
1 Registro de Comisiones
2 Pago de Comisiones a Vendedores
3 Traspasos de cuentas entre Vendedores
Bitcora de operaciones
Para llevar un registro de qu informacin es afectada por un procedimiento, podemos crear una tabla de
auditoria, en donde se escribir el Id del Proceso que tuvo que ver con la entrada, eliminacin o actualizacin
del registro. Por ejemplo, supongamos que en el cuerpo de nuestro procedimiento para registro de comisiones
contiene la instruccin:
INSERT INTO COMISION (IdEmpleado, Comision)
VALUES (@IdEmpleado, @Comision)
Inmediatamente despus (y dentro de la misma transaccin) podramos colocar la siguiente instruccin,
haciendo referencia a nuestro catalogo de procesos:
INSERT INTO BITACORA_OPERACION (IdProceso, DescProceso, FechaAlta)
VALUES (@IdProceso, @DescProceso, @Getdate)
En donde @IdProceso tiene el valor de 1, y @DescProceso contiene el texto ingresado por el usuario para
justificar esta comisin. Esto es muy til para el seguimiento a informacin e incluso puede ser un
requerimiento de seguridad o cumplimiento de normas en un corporativo.
Evitar la ejecucin duplicada
Imaginemos que ejecutamos nuestro procedimiento de calcular comisiones de vendedores y ste introduce la
informacin en una tabla. Qu sucedera si volviramos a ejecutar el mismo proceso por error? Bueno, no es
difcil de imaginar, tendramos informacin duplicada. Para evitar esto, podemos apoyarnos en nuestra tabla
de bitcora, consultando si nuestra operacin ha sido ejecutada recientemente, antes de ejecutarla. A nivel de
interfaz, podramos mostrarle al usuario un mensaje ms descriptivo.
Depuracin de variables
En caso de no contar con herramientas con capacidades de depuracin para stored procedures, se puede
usar la instruccin Select para conocer los valores que van tomando las variables al ejecutar el proceso, por
ejemplo:
SELECT @Variable AS Variable
Por otro lado, cuando hay una falla en la ejecucin del procedimiento, es muy probable que el valor de la
variable nos aparezca vaco, por lo que esta instruccin no es muy til para depurar fallas. En ese caso, la
recomendacin sera basarnos en el mensaje de error que arroje el servidor de base de datos donde indica la
lnea de cdigo donde se est dando el error, y entonces utilizar cerca de esa lnea la instruccin PRINT para
que nos de un valor que permita ejecutar esa instruccin fuera del procedimiento y poder observar lo que est
sucediendo.
Por ejemplo si el mensaje de error indica que el Subquery asignado a una variable est regresando ms de un
valor, podemos hacer un print para conocer los valores que se estn usando para armar el query, y detectar el
problema.
PRINT @IdEmpleado
SET @VarIdComision =
(SELECT IdComision FROM Comision where IdEmpleado = @IdEmpleado)
Monitoreo de la informacin
No porque nuestros procedimientos no marquen errores significa que funcionan correctamente. Por ejemplo,
si en un procedimiento tenemos la instruccin IF @Variable > 1 y el proceso nunca entra en el IF (cuando se
supone que debi haber entrado), entonces hay algo mal. Una herramienta de anlisis de cdigo nos ayudara
a conocer nuestra cobertura de cdigo, pero dado que stas herramientas no son comunes para stored
procedures, lo ms seguro es que debamos recurrir a monitorear esto manualmente revisando nuestros datos
y la bitcora de operaciones.
Bitcora de incidencias
Cuando ocurre algn error en nuestro proceso es bueno anotar en una bitcora por qu se dio el error y cmo
se solucion. En ocasiones, los errores se dan no porque est mal nuestro proceso sino porque hay una
inconsistencia en los datos. Por ejemplo si el proceso busca el Id de un registro con una fecha, pero existen
dos registros con la misma fecha, SQL no sabr cual tomar y el proceso fallar. As que se toma la accin
correctiva correspondiente y se anota en la bitcora para posibles futuras excepciones.
Separacin en funciones
Cuando manejamos grandes cantidades de informacin, es normal que los procesos que desarrollemos
tengan una gran cantidad de instrucciones dando como resultado cdigo muy largo. El uso de funciones en
SQL permite simplificar el cdigo en ciertas secciones donde necesitemos obtener un valor. Las funciones las
podremos invocar una y otra vez desde nuestros procedimientos.
DECLARE @SaldoActualCta Smallmoney
SET @SaldoActualCta = (SELECT dbo.fnc_ObtenerSaldoActualCuentaXIdCta(@IdCtaLote))
Manejo de cursores
Hay quienes argumentan que no es bueno el uso de cursores porque son supuestamente lentos, pero
considero que hay ocasiones en que es inevitable, e inclusive muy tiles, ya que el uso de cursores nos
permitir avanzar registro por registro y especificar una o varias instrucciones en cada vuelta. Cuando se opte
por usar cursores hay que tener cuidado de cerrarlos correctamente, principalmente cuando utilizamos
cursores anidados (cursor dentro de otro cursor). Otra cosa a tomar en cuenta es que si se produce un error
dentro del cursor, supongamos en un INSERT, cuando manejemos la excepcin, tambin debemos cerrar el o
los cursores involucrados. Por otro lado, para avanzar registro por registro no solamente se cuenta con la
opcin de cursores sino tambin con la instruccin WHILE, pero seria cuestin de revisar cual de estas
opciones se adecua ms a nuestras necesidades.
Tablas temporales
Esta es otra arma que tenemos a nuestra disposicin al manejar grandes cantidades de informacin. Las
tablas temporales permiten almacenar informacin temporalmente, de tal manera que podemos hacer uso de
ella durante la ejecucin de nuestro stored procedure. Recordemos tambin que existen las llamadas
variables de tabla que son similares a las tablas temporales pero utilizan menos recursos y son ideales para
almacenar poco volumen de datos. Se recomienda investigar a fondo las diferencias entre ambas opciones ya
que su explicacin excede el alcance de este artculo.
Disparadores y reglas
Los disparadores (tambin conocidos como triggers) son objetos de la base de datos que ejecutan acciones
cuando se producen ciertos eventos. Por ejemplo imaginemos que a un vendedor inactivo no se le puede
asignar una cuenta. Mediante un disparador podremos prevenir esta situacin.
Si al ejecutar el procedimiento se da esta situacin, entonces aparecer un mensaje que impedir que se
termine de ejecutar el SP correctamente. Esto es bueno para nosotros, porque es una advertencia de que
algo anda mal en nuestro procedimiento. Por otro lado, las reglas (rules) nos permiten establecer ciertos
limites a la informacin. Por ejemplo, imaginemos que el saldo de un vendedor no puede ser menor a 1,000
pesos. Para esto podemos crear una regla.
El uso de disparadores y reglas en la construccin de procedimientos es fundamental. De hecho, se
recomienda que antes de programar el procedimiento, se programen todos los disparadores y reglas
necesarias. Esto nos obligar a programar el proceso respetando siempre las reglas de negocio
preestablecidas. El uso de disparadores y reglas nos garantizara que la informacin que resulte de nuestros
procesos ser confiable.
Conclusin
Los stored procedures son fundamentales para el desempeo ptimo de un sistema de informacin. A los
desarrolladores de sistemas de informacin nos corresponde implementar todo tipo de estrategias y tcnicas
que nos permitan tener el control de la informacin y garantizar que sta sea confiable y precisa. Espero que
los tips compartidos en este artculo los ayuden a lograr esta tarea.
Referencias
Solid Quality Learning. Microsoft SQL Server 2005: Tcnicas Aplicadas, Microsoft Press.