Estándares y buenas prácticas de SQL. Cuando trabajamos con SQL o bien cuando tenemos la necesidad de crear procedures (utilizando pl/sql), es recomendable.

Presentación del tema: "Estándares y buenas prácticas de SQL. Cuando trabajamos con SQL o bien cuando tenemos la necesidad de crear procedures (utilizando pl/sql), es recomendable."— Transcripción de la presentación:

1 Estándares y buenas prácticas de SQL

2 Cuando trabajamos con SQL o bien cuando tenemos la necesidad de crear procedures (utilizando pl/sql), es recomendable utilizar algunos estándares como los siguientes: - Cada función o procedure que hagamos, debemos documentarla de la mejor manera posible (utilizando al mismo tiempo buenas prácticas de programación). Esto permite que otras personas, al encontrar nuestro código lo suficientemente claro, puedan comprender y utilizar dichas funciones sin mayor problema. En el caso en particular de OpenACS, el cual está pensado para un ambiente open source, al emplear buenos estándares, tenemos una buena probabilidad de que nuestro trabajo pueda ser mantenido y/o adaptado por cualquier persona de manera sencilla (ya que cualquiera puede tener acceso a nuestro contenido). - Para fines de mantenimiento y realización de upgrades de nuestro software, es conveniente empaquetar nuestras funciones o procedures. Con esto, podemos ver/corregir bugs, además de facilitarnos el proceso de actualización de nuestro sistema.

3 - Cuando utilizamos sentencias en nuestros procedures como la siguiente, hacemos que el reload de paquetes sea más sencillo. + create or replace procedure|function - Esta es una buena forma de escribir el esquema de nuestras funciones; tratando de que no sólo el contenido se entienda, sino también que cada línea de código sea lo suficientemente legible para el usuario.

4 * Colocando el nombre de las tablas y de los campos en SQL. - Debemos utilizar nombres descriptivos, tanto para las tablas como para los campos, cuya longitud no sea muy extensa. De lo contrario, al realizar queries que requieren mayor complejidad, puede llegar a ser tedioso hacer referencia a los campos de nuestra tabla; peor aún en el caso que tengamos una relación en la cual tengamos muchos campos. Ejemplo: Si consideramos una tabla que guarda el username y password de una persona X y asumiendo que es una base de datos que contiene muchísimas tablas. - Al definir el esquema de la tabla de la siguiente forma, puede llegar un momento en el cual nos sea complicado recordarnos de la forma en la cual podemos hacer referencia a dicha tabla. + create table cosa(pato1 integer, gallina1 string, primary key(pato1,gallina1));

5 - Es recomendable colocar todo, excepto %TYPE|%ROWTYPE, en minúsculas, esto para que nuestra aplicación sea consistente a través de varias aplicaciones. - * Ventajas al darle nombre a las restricciones (constraints) - - Me permite identificar y modificar facilmente errores. - - Confiablemente puedo modificar o eliminar constraints.