Lineamientos generales para la codificación SQL

Pinal Dave, MVP (Most Valuable Professional) en SQL Server, publicó hace un tiempo una guía de “estándares” para la codificación en SQL Server (Parte 1, Parte 2), aunque la mayoría de los lineamientos pueden ser aplicados tranquilamente en cualquier código SQL.

A pesar que los estándares suelen limitarnos mucho y darnos la sensación de perder creatividad en algunos aspectos, son mucho más preferibles que a no tenerlos.

Publico abajo algunas de las reglas mencionadas en el blog de sqlauthority traducidas al español y aplicables a SQL en general (no enfocado directamente en TSQL). 

• Utilizar la notación de “Pascal” para objetos como tablas, vistas y stored procedures. Es decir, escribir palabras todas juntas separadas por mayusculas. Además, no está mal terminar con “s”. Por ejemplo:

UserDetails
Emails

• Utiliza un prefijo para todo gran grupo de tablas. Por ejemplo:

Page_UserDetails
Page_Emails

• Utiliza las siguientes convenciones para nombras stored procedures, triggers, indices, foreign keys y primary keys.

• Stored procedures: sp<Nombre de Aplicacion>[_<grupo>_]<tipo de accion><nombre de tabla>. Donde acción es un verbo como Get, Delete, Update, Write, Archive, etc. Por ejemplo:  spUserAdministration_Page_UpdateEmails
• Triggers: TR_<nombre de tabla>_<action><description>. Por ejemplo:  TR_Emails_LogEmailChanges
• Indices: IX_<nombre de tabla>_<columnas separadas por _>. Por ejemplo:  IX_UserDetails_UserID
• Claves primarias: PK_<nombre de tabla>. Por ejemplo: PK_UserDetails
• Claves externas: FK_<tabla 1>_<tabla_2>

• Evita el uso de SELECT *. Usa nombres de columnas a continuación de la sentencia SELECT.

• Indenta las consultas SQL. Por ejemplo:

SELECT Username, Password
FROM UserDetails ud
INNER JOIN Employee e ON e.EmpID = ud.UserID
en vez de:
SELECT Username, Password FROM UserDetails ud INNER JOIN Employee e ON e.EmpID = ud.UserID

• Escribe las sentencias SQL en mayúsculas.
• Intenta utilizar la primary key en las condiciones de los UPDATEs o DELETEs.
• Crea los stored procedures en la misma base de datos donde existe la tabla.
• En vez de utilizar un LOOP para insertar datos de una tabla A a una tabla B, intenta usar INSERT INTO… SELECT…
• Evita utilizar espacios o palabras reservadas para el nombre de los objetos de la base de datos.
• Intenta escribir comentarios en todo stored procedure, trigger o batch sql.
• Evita utilizar wildcards al principio de una palabra en una búsqueda con LIKE.
• Cuando utilices JOINs, siempre utiliza el nombre de la tabla delante del nombre de la comlumna. Adicionalmente, se puede agregar nombre del servidor, nombre de la base de datos y/o propietario.
• Cuando tienes condiciones con varias ramas, utilizar paréntesis puede mejorar la lectura de expresiones complicadas.
• Utiliza — para comentar una línea simple y /* */ para marcar una sección se código comentada.
• Analiza todas las consultas y optimizalas. Por ejemplo: SHOWPLAN_ALL en TSQL o EXPLAIN en MySQL.
• Utiliza vistas para datos frecuentemente requeridos, con JOINs y/o cáculos complicados.
• Evita guarda datos binarios o imágenes en la base de datos. En vez de eso, es preferible guardar el path de donde se almacena la imagen o el archivo en el servidor.
• Utiliza siempre la lista de columnas de un INSERT. Esto previene problemas cuando cambie la estructura de la tabla.
• Realiza todas las tareas de chequeos de integridad y validaciones de datos por medio de constraints en vez de triggers.
• No utilices números de columnas en la cláusula ORDER BY, puesto esto puede reducir la legibilidad de la consulta SQL. Por ejemplo:

SELECT UserID, UserName, Password
FROM UserDetails
ORDER BY UserName
en vez de
SELECT UserID, UserName, Password
FROM UserDetails
ORDER BY 2

Puedes diferir de algunas de las reglas antes mencionadas, pero el objetivo no es imponer reglas sino simplemente tener un marco sobre el cual trabajar de manera prolija y ordenada.  De hecho, puedes armar tu propio estándar de codificación para tu grupo de trabajo.

Via: ecuador.latindevelopers.net