Usando SPs para más que SQL

Un SP (Stored Procedure = Procedimiento Almacenado) es un bloque de código que ejecuta una secuencia de operaciones sobre una base de datos relacional. Un SP es una excelente forma de encapsular operaciones que se ejecutan con frecuencia. Ese encapsulado aporta además un nivel de seguridad adicional, ya que no permite la ejecución de instrucciones de SQL ajenas por medio de ellos. Es decir, protege contra la inyección de SQL. Es mucho más rápido ejecutar un SP que volver a ejecutar toda la secuencia de sentencias, ya que cuando se crea, se hace un proceso similar a la compilación para verificar su correcta estructura, de eta forma, cada vez que se ejecuta ya no tiene que verificarse, en contraparte con ejecutar la secuencia de instrucciones que se verifica en cada ejecución. Los SSPP se utilizan para realizar inserciones de registros en más de una tabla, su edición, eliminación y consulta. de una manera transparente a los programadores de las aplicaciones.

Estas características son las que, de manera personal, me motivan a analizar una BD y optimizarla desde este punto de vista, ya que permite detectar inconsistencias y algunas deficiencias en su funcionamiento.

Cuando se desarrollan los SSPP, se debe procurar tener una consistencia en la forma de diseñarlos, en los argumentos que recibe, se deben manejar los casos de valores nulos en los parámetros y asígnales nombres que den idea del tipo de resultado esperado. Una recomendación al crear SSPP es que agrupen tareas con base en las tablas que utilizan, por ejemplo, un SP que por medio de opciones realice inserciones, actualizaciones, eliminaciones o consultas.

Cuando se traten de consultas sobre varias tablas es mejor, cuando estas combinaciones son frecuentes, crear vistas, ya que tienen un efecto similar en el motor de la BD, ya que revisa su validez solo cuando son creadas o modificadas, y al momento de recuperar los datos es más rápido (en publicaciones posteriores se tratarán estas).

Parte de la documentación que se ha de construir a partir del análisis es un diccionario de datos que describa los nombres de los parámetros, tipos de datos, longitudes y en qué SSPP se utilizan. Esto ayudará a homogeneizar las definiciones, simplificar el mantenimiento y automatizar el desarrollo, especialmente si se trata de un proyecto con un alto grado de dinamicidad (es tan dinámico que lo dinámico parece estático)

La siguiente consultas en SQL puedee ayudar para obtener datos para los diccionarios y la documentación. Está escrita para funcionar en servidores de SQL Server

select SP.object_id, SP.name Procedimiento, P.parameter_id [Id Parámetro], P.name Parámetro, T.name Tipo, P.max_length Longitud
from (select object_id, name from sys.objects where type = 'P') SP left join
(select object_id, parameter_id, name, system_type_id, max_length from sys.parameters) P
on SP.object_id = P.object_id left join sys.systypes T
on P.system_type_id = T.type

El resultado de la consulta anterior se puede copiar en una hoja electrónica.

Una de las ventajas de realizar un proceso de optimización es el de reducir la cantidad de objetos existentes en la BD. Agrupando SSPP se consigue estandarizar tipos de datos utilizados y menor cantidad de parámetros que es igual a menos código repetitivo, menos cosas por revisar, menos trabajo (quitando el innecesario).

¿Dudas, preguntas y sugerencias? En comentarios (abajo de la publicación) o al correo admin@msg-fs.com. No te pierdas nuestros “Twits” en https://twitter.com/MSG_FS y nuestra pagina en face: https://www.facebook.com/SernaSistemas/