Si recién estás empezando con Firebird o con bases de datos relacionales entonces es posible que te hayas hecho la pregunta que da título a este artículo.

Con todo derecho podrías preguntarte: ¿para qué me servirá usar stored procedures? ¿qué ganaré si los uso?

En primer lugar hay que aclarar que no es obligatorio usarlos. Todo lo que puedes hacer dentro de un stored procedure también puedes hacerlo en el código fuente de tu lenguaje de programación.

Sin embargo, las ventajas de usar stored procedures son varias y muy importantes:

  1. Rapidez
  2. Seguridad
  3. Independencia
  4. Trabajo en equipo
  5. Encapsulamiento
  6. Capas separadas

Veamos cada una de esas ventajas con más detalle:

Ventaja 1. Rapidez

Esta ventaja a su vez se divide en tres partes:

a) Procesamiento en el Servidor

b) Optimización de los resultados

c) Velocidad en la codificación

Procesamiento en el Servidor

Procesar los datos en el Servidor es muy rápido por varios motivos: por un lado, los datos no deben estar viajando por la red, solamente los resultados finales lo harán. Por ejemplo, si deseas calcular los impuestos a pagar este mes, y la tabla tiene 250.000 filas, el procesamiento de esas 250.000 filas se hará en la memoria de la computadora donde se encuentra el Servidor, no deberán estar viajando por la red para llegar a la computadora Cliente y ser procesadas allí, así que la ganancia en la velocidad de respuesta será muy notoria. Por otro lado, generalmente la computadora donde se encuentra el Servidor es más poderosa que todas (o la mayoría) de las computadoras que usan los Clientes y por lo tanto procesará los datos más rápidamente. Así que sumadas ambas ventajas, la ganancia en velocidad puede ser muy grande.

Optimización de los resultados

Los programas de administración gráfica (como el EMS SQL Manager) te pueden mostrar gráficamente el uso de los índices, y la cantidad de filas de cada tabla que fueron procesadas. Mirando esos gráficos puedes notar que se están procesando más filas de las necesarias o que no se están usando los índices correctos. Entonces, tomando eso en cuenta puedes corregir tu stored procedure y conseguir que realice sus tareas más rápidamente.

SP01

Captura 1. Si haces clic en la imagen la verás más grande

En la Captura 1. podemos ver la cantidad de filas que se procesaron en cada tabla. Si conocemos la cantidad de filas de cada tabla (lo cual se puede averiguar muy fácilmente con un SELECT COUNT(*) ) y lo que hace nuestro stored procedure entonces podemos notar que alguna tabla está procesando más filas de las necesarias, o que no usa un índice cuando sí debería usarlo.

Velocidad en la codificación

Cuando escribes un stored procedure allí mismo puedes verificar que esté funcionando correctamente, con un solo clic ya lo ejecutas. Y si no está funcionando correctamente, entonces lo corriges y lo vuelves a ejecutar hasta conseguir los resultados deseados. Hacer eso mismo en tu lenguaje de programación te hará demorar más tiempo porque tendrás que ejecutar tu programa, hacer unos cuantos clics aquí y allá y recién después de eso obtendrás los resultados.

Ventaja 2. Seguridad

En un stored procedure solamente puedes usar tablas y columnas que existen en la Base de Datos. Si escribes mal el nombre de una tabla o de una columna, no podrás compilar el stored procedure. De eso se deduce que los errores serán encontrados en tiempo de compilación y no en tiempo de ejecución. Encontrar errores en tiempo de ejecución puede ser muy malo si es un usuario quien los encuentra. Está muy apurado, necesita procesar algo, y recibe el mensaje: “Table unknown” o el mensaje: “Column unknown”. De seguro que no le va a gustar. Algo así no puede pasar si se usó un stored procedure porque el Firebird no permite compilar un stored procedure que tenga esos errores.

Ventaja 3. Independencia

Como los stored procedures se guardan dentro de la Base de Datos están disponibles para ser usados por cualquier programa que se conecte a esa Base de Datos. Ese programa puede estar escrito en cualquier lenguaje de programación (Visual FoxPro, Visual Basic, Delphi, Java, C, C++, etc.).

Por lo tanto, si hoy usas un lenguaje de programación y dentro de unos días decides usar otro lenguaje de programación nada tendrás que cambiar dentro de la Base de Datos, todo estará allí, esperando ser usado.

Y en consecuencia no dependes de un lenguaje de programación, eres independiente, libre de usar cualquier lenguaje que desees.

Ventaja 4. Trabajo en equipo

Esta ventaja está muy relacionada con la anterior. Como los stored procedures son independientes de los lenguajes de programación entonces una persona puede programar en Visual FoxPro, otra persona puede programar en Visual Basic, otra persona puede programar en Delphi, etc. y todos podrán llamar a los mismos stored procedures.

Así, cada programador puede programar en el lenguaje de su preferencia, sin ningún problema.

Además, varias personas podrían estar escribiendo varios stored procedures inclusive al mismo tiempo. Si Juan conoce muy bien el tema de los impuestos entonces a él se le asigna esa tarea, y si María conoce muy bien como procesar los saldos entonces a ella se le asigna esa tarea.

Ventaja 5. Encapsulamiento

Después de compilar un stored procedure se puede dar derechos de ejecución sobre ese stored procedure a un usuario o a un rol o a un programa, quienes nunca verán el código fuente de dicho stored procedure, simplemente lo usarán.

Ventaja 6. Capas separadas

La programación en 3 capas es una metodología muy útil a seguir para construir aplicaciones de calidad porque cada capa se encarga exclusivamente de una tarea.

En la capa de datos se procesa todo lo que tenga que ver con tablas y columnas de una Base de Datos.

La idea es la siguiente: “todo lo que puede procesarse dentro de una Base de Datos debe procesarse dentro de esa Base de Datos”.

La ventaja de la programación en 3 capas es que no se tiene código mezclado. Cada capa (capa de presentación, capa de negocios, capa de datos) siempre se encarga de una sola tarea. Es más fácil de entender que si está todo mezclado.

En el caso de la capa de datos, está se encargará de:

  • Insertar, actualizar, o borrar filas de las tablas
  • Procesar el contenido de las tablas
  • Devolver a la capa de negocios los resultados que ésta solicitó

Conclusión:

Aunque no es obligatorio usar stored procedures, es altamente recomendable utilizarlos porque las ventajas son muchas y muy grandes.

Los principiantes en Firebird o en bases de datos relacionales pueden ser un poco reacios a su utilización pero una vez que empiezan a usarlos se dan cuenta de lo muy provechoso que les resulta.

NOTA: ser principiante no es un defecto, todos hemos sido principiantes alguna vez, nadie nació siendo experto en Firebird, todo lo que sabemos lo hemos aprendido mucho después de nacer.

Artículos relacionados:

Entendiendo a los stored procedures

Escribiendo un stored procedure

Similitudes y diferencias entre stored procedures y triggers

¿Es conveniente usar stored procedures?

El índice del blog Firebird21

El foro del blog Firebird21