SQL, como su propio nombre indica, es un lenguaje de programación. Y como lenguaje puede programarse bien o mal, puede ser legible o no. Puede escribirse de una forma más o menos propensa a la introducción de bugs. Poco importa, de cara al clean code, si se trata de un lenguaje orientado al manejo de datos, o a un lenguaje de POO.

Obviamente, no aplican las mismas reglas en Java o C# que en SQL, aún así, la mayoría de los principios siguen siendo válidos.

Los principios de la programación limpia no dejan de ser: hacer código legible para otros programadores, código flexible y que no facilite la entrada de nuevos bugs.

Veamos algunas prácticas en SQL qie ayudan a cumplir estos principios.

Select *

Evita los select *. Tu funcionalidad tiene unos requerimientos concretos y por tanto se espera  que devuelva una lista de campos concreta. Más tarde esa query, ya sea en sistema concreto, en un procedimiento almacenado o en una función será usado por otro trozo de código. Es probable que el trozo - o trozos - de código que usa la consulta espera un número concreto de campos en un orden determinado. Si usamos select * y alguna de las tablas implicadas cambia, ya sea porque se introduce una nueva columna, o porque se reordenan las columnas internamente, la tabla devuelta por la query cambia. Como resultado es probable qie ese trozo de código que usa tu consulta falle.

Usa los campos en los insert

Básicamente es un caso totalmente análogo al anterior. La definición de tu tabla puede cambiar, incluso para temas tan sencillos y aislados de tu funcionalidad como sería incluir una columna de auditoría. Si no incluimos los campos en el insert, al incluir una nueva columna tu query fallará. Lo peor es que como se trata de un daño colateral, no siempre es fácil de detectar donde está el error.

Todos nuestros campos tienen nombre

Debemos ser cuidados con la nomenclatura también en SQL, ya sea si creamos variables en un procedimiento, si creamos un procedimiento almacenado o si estamos haciendo uso de una función de agregado.

Si hacemos una query de tipo select que devuelve un campo mediante una función de agregado, por ejemplo SUM, pongámosle un nombre a ese campo mediante los alias. De lo contrario tenemos que acceder a ese campo por posición y corremos el riesgo de que algo cambie y el código que utiliza esta query empiece a fallar.

Manejo de alias

Los alias ayudan mucho a simplificar las queries, pero hay que tener bastante cuidado en cómo usarlos. Lo primero es tener en cuenta que si trabajas con varias tablas, uses alias o no, siempre pongas el prefijo para saber de qué tabla es el campo con el que estás trabajando.

Yo suelo mantener ciertas reglas. En consultas relativamente pequeñas uso alias de una o dos letras que permitan identificar claramente la tabla en cuestión. En consultas más grandes uso más caracteres si es necesario. Siempre teniendo en cuenta que la legibilidad es importante, y cuanto más grande es un bloque de código y más separado está la definición de un nombre de su uso más difícil es saber a qué se refiere ese nombre.

Formateo

Crucial formatear correctamente el código, al igual que en cualquier otro lenguaje. El problema con SQL es que no hay un estándar aceptado por toda la comunidad, pero de cualquier forma lo importante es que se decida uno en el seno del proyecto y se aplique.

Algunos consejos sobre el formateo de código SQL:

Cada bloque de sentencia en una nueva línea

SELECT campo1, campo2, campo3
FROM tabla1 t1
INNER JOIN tabla2 t2 ON t1.id = t2.id
WHERE t1.cod_provincia = 36
ORDER BY t2.campo2

Palabras reservadas de SQL en mayúscula

SELECT campo1, campo 2
FROM tabla1

Objetos de base de datos en minúsculas

SELECT campo1, campo 2
FROM tabla1

Divide en líneas cláusulas muy grandes

Si tienes por ejemplo un WHERE con muchas condiciones formatéalas de forma que se vean claramente donde empiezan y donde acaban mediante saltos de línea y espacios como tabuladores.

Estándares de codificación

Define unos estándares a nivel de proyecto o empresa y seguidlos a rajatabla. Se debe tomar decisiones de definición como:

Triggers

Debemos a toda costa evitar el uso de triggers para el manejo de datos, más allá de temas puros de auditoría. Si la lógica de datos de nuestra aplicación (ya no digamos la lógica de negocio) depende de una serie de triggers vamos a tener problemas de bugs ocultos seguros.

Los triggers son muy malos compañeros del código limpio, ya que modifican la información de las tablas de una forma muy opaca. Generalmente tenemos nuestros procesos lógicos controlados, sabiendo porque puntos y estados pasan nuestros datos, pero los triggers se saltan toda esa lógica ejecutándose cuando ocurren ciertas acciones en la base de datos. Por eso mismo, es muy difícil detectar cuando tenemos un error o un problema a consecuencia de un trigger. De hecho, para saber que tenemos un trigger afectando a nuestra funcionalidad o lo “olemos” (sospechamos que hay algo extraño afectando al proceso) o lo tenemos muy bien documentado (tendríamos que acordarnos de ir a ver la documentación). Esto es contrario a los principios de código limpio simple, que se entiende según lo lees y hace lo que se espera al ver el código escrito. Es contrario porque tenemos agente extraño toqueteando nuestro código.

Un buen uso de los triggers puede ser para añadir datos de auditoría de forma que por ejemplo, guardemos automáticamente en un tabla de backup o histórico cada vez hagamos un cambio sobre un registro.

Modulariza

Al igual que en nuestro código en JAVA nuestras funciones deben ser pequeñas, en SQL también deberíamos intentar hacer consultas pequeñas y modulares. Para ello los diferentes SGDB nos proporcionan herramientas como los procedimientos almacenados o las funciones. Tiremos de ellas para reducir la complejidad de cada consulta al máximo.

Lógica de negocio en SQL

Salvo contadas excepciones por temas de rendimiento debemos evitar tener nuestra lógica de negocio en SQL. SQL lo debemos usar para el manejo de datos. Solo debemos tener consultas complejas cuando sea necesario para el movimiento o ciertos cálculos de datos, pero la responsabilidad de la lógica de nuestra aplicación debe estar en nuestra aplicación, no en la base de datos.

Resumen

SQL también es código, y por lo tanto requiere de tu cariño, atención y cuidados.

Si te interesa la temática clean code, aquí tienes algunos artículos que podrían interesarte: Clean Code. Cleaning the code , Cleaning the code: Nomenclatura o la importancia de llamarse Ernesto , Cleaning the Code: Introducción al testing.