Volver a la lista de artículos Artículos
Lectura de 9 minutos

24 reglas del estándar de formato SQL

Author's photo
Dorota Wdzięczna

Escribir consultas a una base de datos requiere conocimientos sobre la sintaxis de SQL, pero esto no es todo lo que debes saber. Las mejores prácticas para escribir código SQL profesional requieren buenas habilidades de formato. En este artículo discuto por qué esto es tan importante y cuáles son las reglas básicas que debes seguir.

¿Por qué vale la pena formatear el código SQL?

Los programadores principiantes de SQL a menudo no prestan mucha atención al formateo de su código. Si crees que el formato es algo que se puede ignorar con seguridad, mira el código de abajo:

SELECT id, FirstName, LASTNAME,c.nAme FROM people p left JOIN cities AS c on c.id=p.cityid;

Esta consulta SQL de arriba ha sido escrita sin usar ninguna regla de formato. Ahora compárala con la consulta formateada de abajo, que es el mismo código:

     SELECT p.PersonId,
            p.FirstName,
            p.LastName,
            c.Name
       FROM Person AS p 
  LEFT JOIN City AS c 
         ON p.CityId = c.CityId;

¿Ves la diferencia? ¿Cuál es más legible? ¿Qué consulta es más fácil de entender?

Por supuesto, es obvio que la primera consulta no es muy fácil de leer. Aparte de esto, también es un problema hacer cambios en este código rápidamente. Si quisieras comparar esta consulta con otra similar, no sería una tarea fácil. La segunda consulta es completamente diferente, aunque es exactamente el mismo código: es fácil de leer, sería fácil corregir el código y sería sencillo compararlo con otro código bien formateado. Un formato adecuado del código SQL ayuda a los programadores a evitar errores.

Bien, ahora entiendes por qué formatear el código SQL puede ser una buena idea. Ahora es el momento de aprender cómo hacerlo.

Cómo formatear el código SQL

Hay diferentes maneras de abordar el formateo del código. Algunos programadores SQL tienen estilos y preferencias individuales para formatear las consultas SQL. Tienen experiencia en programación y siguen las reglas que les resultan convenientes. Esto no es malo si sólo estás trabajando en tus propios proyectos, pero ¿qué pasa si estás trabajando junto con otros compañeros de trabajo? Trabajar en equipo sería problemático si cada programador escribiera el código utilizando su propio estilo individual. El código representaría una mezcla de normas en un solo proyecto. La solución sería establecer un conjunto de principios para todo el equipo. Pero entonces, ¿qué pasa si el código tiene que ser leído o corregido por personas ajenas a la empresa? La mejor solución, en general, es seguir la Norma de Formato SQL. No existe un documento oficial al respecto, pero hay algunas normas y buenas prácticas generalmente acordadas y escritas por expertos en SQL. Además, hay muchas herramientas que ayudan a formatear el código SQL que se basan en este estándar. En esta guía discutimos las reglas comunes y populares que se basan en este estándar.

Nombrar objetos

Primero discuto las reglas generales para nombrar los objetos de la base de datos. Estas son las reglas más comunes:

  • Evitar el nombre de una tabla/columna en plural. Es mejor utilizar employee en lugar de employees.
  • Si el nombre de la tabla o columna debe constar de más de una palabra, utilice un guión bajo para unirlas, por ejemplo employee_city. Algunos profesionales prefieren utilizar en su lugar el llamado estilo CamelCase, por ejemplo EmployeeCity. El estilo preferido es diferente para los distintos sistemas de bases de datos relacionales.
  • Compruebe que el nombre no se utiliza ya como palabra clave en SQL.
  • Si el nombre es el mismo que una palabra clave de SQL, encierre el nombre entre comillas.
  • El nombre de un objeto en una base de datos para una tabla o una columna debe ser único y no demasiado largo. Evite los caracteres especiales en el nombre como $, &, * , etc. (utilice sólo letras, números y guiones bajos).
  • Utilice un guión bajo en un nombre sólo si es necesario.
  • No empieces el nombre con un guión bajo.
  • Utilice comentarios sólo si es necesario.
  • Evite las abreviaturas, pero, si las utiliza, asegúrese de que se entienden.
  • Evita dar el mismo nombre a una tabla y a una columna.
  • Utilice las mismas reglas de denominación para los alias de columnas o tablas.
  • Incluya la palabra clave AS para crear alias, ya que esto hace que el código sea más legible.
  • Para la columna de clave primaria evite el nombre id. Una buena idea es combinar id con el nombre de una tabla, por ejemplo: id_employee.

Alineación

La mayoría de los expertos recomiendan escribir primero las palabras clave en una nueva línea a la izquierda y luego el resto del código a la derecha, así:

SELECT p.PersonId,
       p.FirstName,
       p.LastName,
       c.Name
  FROM Person AS p 
  JOIN City AS c 
    ON p.CityId = c.CityId;

Indentación

El uso liberal de las nuevas líneas puede ayudar mucho a la legibilidad de una consulta SQL. Es una buena idea usar una nueva línea para cada consulta separada y usar una nueva línea para cada columna separada después de una coma. Del mismo modo, es una buena idea usar espacios para rodear el operador igual, usar espacios antes o después de los apóstrofes, y usar un espacio después de una coma.

Las secciones siguientes presentan más detalles sobre las buenas prácticas de indentación en diferentes tipos de consultas SQL.

Comentarios

Evite escribir demasiados comentarios en el código. Por supuesto, hay casos en los que los comentarios son necesarios, pero normalmente es mejor utilizar comentarios de varias líneas que se indican con los caracteres de apertura /* y de cierre */. Se recomienda escribir este tipo de comentarios al principio de una nueva línea, en lugar de empezar en una línea con código que se ejecuta. El comentario debe escribirse por encima de la línea de código SQL correspondiente, utilizando la misma sangría. Por ejemplo:

SELECT p.PersonId,
       p.FirstName,
       p.LastName,
       /* Name column is the name of the city: */
       p.Name,
  FROM Person AS p 
 WHERE p.Name = 'New York';

En el código SQL también es posible añadir comentarios de una línea. Este tipo de comentario se indica con un doble guión (--) al principio del texto del comentario. Todo el texto después de estos caracteres se trata como un comentario.

SELECT -- we have to delete this column p.PersonId,
       p.FirstName,
       p.LastName,
       p.Name
  FROM Person AS p;

Consultas SELECT

En este tipo de consulta SELECT es la primera palabra del comando. Si hay muchas columnas después de SELECT, es mejor separarlas colocando cada una en una línea distinta. Cada nueva línea debe tener una sangría. Asegúrese de colocar comas al final de la línea y no al principio de la misma. 

SELECT p.PersonId,
       p.FirstName,  
       p.LastName,
       c.Name
  FROM Person AS p;

Para las palabras clave FROM, WHERE, ORDER BY, GROUP BY, y HAVING, escriba cada una en una nueva línea sin sangría. 

SELECT p.PersonId,
       p.FirstName,
       p.LastName,
       p.Name,
  FROM Person AS p 
 WHERE p.Name = 'New York';

Si la sentencia WHERE tiene más de una condición, separe cada condición con una nueva línea con sangría y utilice una nueva línea con sangría con los operadores condicionales AND o OR dentro de la sentencia WHERE.

SELECT p.PersonId,
       p.FirstName,
       p.LastName,
       p.Name
  FROM Person AS p 
 WHERE p.Name = 'New York' 
    OR p.Name = 'Chicago';

Sentencias JOIN

Si une tablas, utilice nuevas líneas para los operadores INNER JOIN, LEFT JOIN, etc. Para el operador ON, escriba una nueva línea con sangría dentro de la sentencia JOIN. Sin embargo, si hay más de una condición, utilice una nueva línea con sangría antes del operador condicional AND o OR.

SELECT p.PersonId,
       p.FirstName,
       p.LastName,
       c.Name
  FROM Person AS p 
  JOIN City AS c 
    ON p.CityId = c.CityId;

Una consulta SQL larga y anidada

Las consultas largas a veces contienen subconsultas. En esta situación la subconsulta debe estar en una nueva línea con sangría.

Para la estructura CASE coloque cada WHEN y END en una nueva línea.

SELECT p.PersonId,
       p.FirstName,
       p.LastName,
       CASE 
         WHEN p.Age < 18 THEN 'below 18'
         WHEN p.Age >= 18 THEN '18 or more'
       END AS Age
  FROM Person AS p;

Otros tipos de consultas SQL

Existen reglas similares para las consultas que modifican, insertan o eliminan datos.

Utilice la sangría para VALUES en las consultas de inserción:

INSERT INTO Car(id_car, name, year) VALUES
  (1, 'Audi', 2010) ;

En el caso de que insertes más filas en una consulta, escribe cada fila como una nueva línea con sangría:

INSERT INTO Car(id_car, name, year) VALUES
  (1, 'Audi', 2010) ,
  (2, 'Skoda', 2015) ;

De forma similar, en una consulta UPDATE utilice SET y WHERE como en una sentencia SELECT, con una nueva línea sin sangría:

UPDATE Car
SET year = 2012
WHERE Name = 'Audi';

o en una consulta DELETE:

DELETE FROM Car
WHERE Name = 'Audi';

Cómo el mal formato del código SQL conduce a problemas

Un ejemplo de cómo un mal formato conduce a problemas se puede ver en la consulta de abajo, en la que las comas se colocan al principio de cada línea:

SELECT /* we have to delete this column */ p.PersonId
     , p.FirstName
     , p.LastName
     , p.Name
  FROM Person AS p 
 WHERE p.Name = 'New York';

Esto podría tener sentido al principio, pero si se comenta la primera columna para eliminarla, la consulta devolvería un error.

Otro error puede producirse si no se utiliza la sangría y las nuevas líneas. Por ejemplo:

Select person.id_person, person.name, person.age, person.description, person.city from person  where person.age>20 and person.city = ( select name from city where id_city>20)

En este código mal formateado sería muy fácil por error eliminar la cláusula WHERE en la subconsulta cuando lo que se pretendía era eliminar la cláusula WHERE en la consulta principal.

Muchos problemas serán fáciles de encontrar si la consulta está correctamente formateada, especialmente en una consulta larga con cientos de líneas de código.

Resumen

Ignorar el estándar de formato SQL puede causar problemas significativos cuando se colabora con otros programadores. Un formato adecuado ayuda a que su código SQL sea más fácil de leer y ayuda a prevenir errores cuando se hacen cambios en su código. En este artículo he presentado algunas de las normas recomendadas por los expertos que le ayudarán a escribir un código más claro. Escribir un código SQL bonito es un buen hábito de trabajo valorado por los empleadores. Tu código indica tu nivel de profesionalidad y muestra que tienes un enfoque moderno y serio del trabajo. Acepta el reto y conviértete en un programador más profesional.

Tags:

También te pueden interesar