24 règles de la norme de formatage SQL

Pour écrire des requêtes dans une base de données, il faut connaître la syntaxe SQL, mais ce n'est pas tout ce que vous devez savoir. Les meilleures pratiques pour écrire un code SQL professionnel nécessitent de bonnes compétences en matière de mise en forme. Dans cet article, j'explique pourquoi cela est si important et quelles sont les règles de base à suivre.

Pourquoi est-il utile de formater le code SQL ?

Les programmeurs SQL débutants ne prêtent souvent pas beaucoup d'attention au formatage de leur code. Si vous pensez que le formatage est quelque chose que l'on peut ignorer sans risque, regardez le code ci-dessous :

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

La requête SQL ci-dessus a été écrite sans aucune règle de formatage. Comparez-la maintenant avec la requête formatée ci-dessous, qui est le même code :

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

Voyez-vous la différence ? Laquelle est la plus lisible ? Quelle requête est la plus facile à comprendre ?

Bien sûr, il est évident que la première requête n'est pas très facile à lire. En plus de cela, il est également difficile de modifier rapidement ce code. Si vous souhaitez comparer cette requête à une autre requête similaire, ce ne sera pas une tâche facile. La deuxième requête est complètement différente, même s'il s'agit exactement du même code - il est facile à lire, il serait facile de corriger le code, et il serait simple de le comparer avec un autre code bien formaté. Un formatage correct du code SQL aide les programmeurs à éviter les erreurs.

OK, vous comprenez maintenant pourquoi le formatage du code SQL peut être une bonne idée. Il est maintenant temps d'apprendre à le faire.

Comment formater le code SQL

Il existe différentes façons d'aborder le formatage du code. Certains programmeurs SQL ont leurs propres styles et préférences pour le formatage des requêtes SQL. Ils ont de l'expérience en programmation et suivent les règles qui leur conviennent. Ce n'est pas grave si vous travaillez uniquement sur vos propres projets, mais qu'en est-il si vous travaillez avec d'autres collègues ? Le travail en équipe serait problématique si chaque programmeur devait écrire du code en utilisant son propre style. Le code représenterait un mélange de règles dans un seul projet. La solution serait de définir un ensemble de principes pour toute l'équipe. Mais que se passe-t-il alors si le code doit être lu ou corrigé par des personnes extérieures à l'entreprise ? La meilleure solution en général est de suivre la norme de formatage SQL. Il n'existe pas de document officiel à ce sujet, mais il existe des normes et des bonnes pratiques généralement acceptées et rédigées par des experts en SQL. En outre, il existe de nombreux outils qui aident à formater le code SQL et qui sont basés sur cette norme. Dans ce guide, nous abordons les règles courantes et populaires qui sont basées sur cette norme.

Nommer les objets

J'aborde tout d'abord les règles générales de dénomination des objets de la base de données. Il s'agit des règles les plus courantes :

• Évitez d'utiliser le nom d'une table/colonne au pluriel. Il est préférable d'utiliser employee au lieu de employees.
• Si le nom de la table ou de la colonne doit être composé de plusieurs mots, utilisez un trait de soulignement pour les relier, par exemple employee_city. Certains professionnels préfèrent utiliser ce que l'on appelle le style CamelCase, par exemple EmployeeCity. Le style préféré est différent pour les différents systèmes de bases de données relationnelles.
• Vérifiez que le nom n'est pas déjà utilisé comme mot-clé dans SQL.
• Si le nom est identique à un mot-clé SQL, mettez-le entre guillemets.
• Le nom d'un objet dans une base de données pour une table ou une colonne doit être unique et pas trop long. Évitez les caractères spéciaux dans le nom comme $, &, *, etc. (utilisez uniquement des lettres, des chiffres et des traits de soulignement).
• N'utilisez un trait de soulignement dans un nom que si cela est nécessaire.
• Ne commencez pas le nom par un trait de soulignement.
• N'utilisez des commentaires que si nécessaire.
• Évitez les abréviations, mais si vous les utilisez, assurez-vous qu'elles seront comprises.
• Évitez de donner le même nom à une table et à une colonne.
• Utilisez les mêmes règles de dénomination pour les alias de colonnes ou de tables.
• Incluez le mot-clé AS pour créer des alias, car cela rend le code plus lisible.
• Pour la colonne de clé primaire, évitez le nom id. Une bonne idée est de combiner id avec le nom d'une table, par exemple : id_employee.

Alignement

La plupart des experts recommandent d'écrire d'abord les mots-clés sur une nouvelle ligne à gauche, puis le reste du code à droite, comme ceci :

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

Indentation

L'utilisation libérale des sauts de ligne peut réellement améliorer la lisibilité d'une requête SQL. C'est une bonne idée d'utiliser une nouvelle ligne pour chaque requête séparée et d'utiliser une nouvelle ligne pour chaque colonne séparée après une virgule. De même, il est bon d'utiliser des espaces pour entourer l'opérateur equals, d'utiliser des espaces avant ou après les apostrophes, et d'utiliser un espace après une virgule.

Les sections ci-dessous présentent plus en détail les bonnes pratiques en matière d'indentation dans différents types de requêtes SQL.

Commentez

Évitez d'écrire trop de commentaires dans le code. Bien sûr, il y a des cas où les commentaires sont nécessaires, mais il est généralement préférable d'utiliser des commentaires de plusieurs lignes qui sont indiqués par des caractères d'ouverture et de fermeture /*. Il est recommandé d'écrire ce type de commentaire au début d'une nouvelle ligne, au lieu de commencer sur une ligne avec le code qui est exécuté. Le commentaire doit être écrit au-dessus de la ligne de code SQL concernée, en utilisant la même indentation. Par exemple :

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';

Dans le code SQL, il est également possible d'ajouter des commentaires d'une ligne. Ce type de commentaire est indiqué par un double tiret (--) au début du texte du commentaire. Tout le texte qui suit ces caractères est traité comme un commentaire.

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

Requêtes SELECT

Dans ce type de requête, SELECT est le premier mot de la commande. S'il y a plusieurs colonnes après SELECT, il est préférable de les séparer en les plaçant sur une ligne distincte. Chaque nouvelle ligne doit être indentée. Veillez à placer les virgules en fin de ligne et non en début de ligne.

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

Pour les mots-clés FROM, WHERE, ORDER BY, GROUP BY et HAVING, écrivez-les sur une nouvelle ligne sans indentation.

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

Si l'instruction WHERE comporte plus d'une condition, séparez chaque condition par une nouvelle ligne indentée, et utilisez une nouvelle ligne indentée avec les opérateurs conditionnels AND ou OR dans l'instruction WHERE.

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

Instructions JOIN

Si vous joignez des tables, utilisez de nouvelles lignes pour les opérateurs INNER JOIN, LEFT JOIN, etc. Pour l'opérateur ON, écrivez une nouvelle ligne en retrait dans l'instruction JOIN. En revanche, s'il y a plus d'une condition, utilisez une nouvelle ligne en retrait avant l'opérateur conditionnel AND ou OR.

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

Une requête SQL longue et imbriquée

Les requêtes longues contiennent parfois des sous-requêtes. Dans ce cas, la sous-requête doit être placée sur une nouvelle ligne en retrait.

Pour la structure CASE, placez chaque WHEN et END sur une nouvelle ligne.

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;

Autres types de requêtes SQL

Il existe des règles similaires pour les requêtes qui modifient, insèrent ou suppriment des données.

Utilisez la mise en retrait pour VALUES dans les requêtes d'insertion :

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

Dans le cas où vous insérez plusieurs lignes dans une requête, écrivez chaque ligne sur une nouvelle ligne avec une indentation :

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

De la même manière, dans une requête UPDATE, utilisez SET et WHERE comme dans une déclaration SELECT, avec une nouvelle ligne sans indentation :

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

ou dans une requête DELETE:

DELETE FROM Car
WHERE Name = 'Audi'; 

Comment un mauvais formatage du code SQL conduit à des problèmes

La requête ci-dessous, dans laquelle les virgules sont placées au début de chaque ligne, est un exemple de la façon dont un mauvais formatage peut entraîner des problèmes :

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

Cela peut sembler logique à première vue, mais si vous commentez la première colonne pour la supprimer, la requête renverra une erreur.

Une autre erreur peut se produire si vous n'utilisez pas l'indentation et les nouvelles lignes. Par exemple :

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)

Dans ce code mal formaté, il serait très facile, par erreur, de supprimer la clause WHERE dans la sous-requête alors que vous aviez l'intention de supprimer la clause WHERE dans la requête principale.

De nombreux problèmes seront faciles à trouver si la requête est correctement formatée, en particulier dans une longue requête comportant des centaines de lignes de code.

Résumé

Ignorer la norme de formatage SQL peut causer des problèmes importants lorsque vous collaborez avec d'autres programmeurs. Un formatage correct facilite la lecture de votre code SQL et permet d'éviter les erreurs lorsque vous apportez des modifications à votre code. Dans cet article, j'ai présenté certaines des règles recommandées par les experts qui vous aident à écrire un code plus clair. Écrire un beau code SQL est une bonne habitude de travail appréciée par les employeurs. Votre code indique votre niveau de professionnalisme et montre que vous avez une approche moderne et sérieuse du travail. Relevez le défi et devenez un programmeur plus professionnel !