Reglas de construcción en PL/SQL

Cuando se definen variables basadas en campos de tablas de nuestro modelo de datos debemos utilizar %TYPE y %ROWTYPE como atributos del tipo de datos. Esto se debe a que cualquier cambio en el tipo de un campo de una tabla de nuestro modelo de datos afectará al código fuente si estos atributos no son usados.

Se recomienda usar SUBTYPE para crear tipos de datos personalizados a partir de un tipo existente en la base de datos. 

Se declararán como constantes aquellas variables que no vayan a cambiar durante la ejecución. De este modo facilitaremos la interpretación del código y eliminaremos posibles errores.

Debemos asegurar que la inicialización lógica de la variable compleja se realiza al comienzo de la sección ejecutable y que no eleva un error. Si la asignación del valor por defecto se realiza en la sección de declaración y falla, entonces el error se propagará por el programa sin ser encapsulado.

Se recomienda usar variables lógicas y funciones en lugar de expresiones complejas para conseguir un código más legible.

Si conocemos una parte de un código o variable que no se va a usar más debemos eliminarla, asegurando previamente que no tiene más presencia en el código.

Debemos crear un procedimiento que limpie las estructuras de datos usadas e incluirlo en cada programa para que sea llamado al final de la sección ejecutable y en cada manejador de excepciones.

Se deben evitar las conversiones implícitas en el código para no tener problemas derivados de delegar la conversión de datos en PL/SQL, como una conversión inesperada de tipos o que las reglas de conversión cambien tras una nueva versión. Por ello, se deben utilizar las funciones predefinidas para la conversión.

Se recomienda crear paquetes para centralizar las definiciones de los tipos ya que permitirá reutilizar dichos tipos en distintos programas.

Las variables globales son peligrosas y deben evitarse ya que, al no ser pasadas a través de la lista de parámetros, es difícil saber cuándo se utilizan en un programa. Estas variables se suelen definir en paquetes, pero hay que tener en cuenta existirán y conservarán su valor durante toda la sesión.

Para mejorar los programas PL/SQL debemos extraer el código estático del cuerpo de los bucles, ya que la ejecución de dicho código estático se realizará tantas veces como iteraciones tenga el bucle. Para ello, el código estático se extraerá del cuerpo del bucle y se asignarán los resultados a variables que, posteriormente, serán llamadas dentro del bucle.

Es muy importante conocer qué tipo de errores se nos pueden plantear y como manejarlos. Debemos definir una estrategia que asegure un manejador por cada excepción conocida, que informe del código de error y escriba el error en un fichero de registro.

Se levantarán excepciones sólo cuando se produzca un error y no para controlar el flujo del programa, por lo que no se debe usar RAISE para abortar el tratamiento normal de un programa y enviar la situación al manejador correspondiente.

No debemos declarar una excepción que pueda ser lanzada por varios motivos, a menos que la pérdida de información sea intencionada, ya que puede dificultar la legibilidad y el entendimiento del código. En su lugar, se declarará una excepción por cada tipo de fallo.

Debemos introducir manejadores de excepciones en aquellos lugares del código que sean susceptibles de producir excepciones.

Debemos introducir la cláusula WHEN OTHERS sólo para excepciones que deben ser capturadas y son desconocidas.