Recherche…


Introduction

Comment écrire de bonnes requêtes SQL lisibles et des exemples de bonnes pratiques.

Formatage et orthographe des mots-clés et des noms

Noms de table / colonne

CamelCase et snake_case sont deux méthodes courantes de formatage des noms de table / colonne:

SELECT FirstName, LastName
FROM Employees
WHERE Salary > 500;
SELECT first_name, last_name
FROM employees
WHERE salary > 500;

Les noms doivent décrire ce qui est stocké dans leur objet. Cela implique que les noms de colonnes doivent généralement être singuliers. Si les noms de table doivent utiliser le singulier ou le pluriel est une question très discutée , mais dans la pratique, il est plus courant d'utiliser des noms de table pluriels.

L'ajout de préfixes ou de suffixes comme tbl ou col réduit la lisibilité, alors évitez-les. Cependant, ils sont parfois utilisés pour éviter les conflits avec les mots-clés SQL et sont souvent utilisés avec des déclencheurs et des index (dont les noms ne sont généralement pas mentionnés dans les requêtes).

Mots clés

Les mots-clés SQL ne sont pas sensibles à la casse. Cependant, il est courant de les écrire en majuscule.

SELECT *

SELECT * renvoie toutes les colonnes dans le même ordre qu'elles sont définies dans la table.

Lorsque vous utilisez SELECT * , les données renvoyées par une requête peuvent changer chaque fois que la définition de la table change. Cela augmente le risque que différentes versions de votre application ou de votre base de données soient incompatibles.

De plus, la lecture de plus de colonnes que nécessaire peut augmenter la quantité d'E / S disque et réseau.

Vous devez donc toujours spécifier explicitement la ou les colonnes que vous souhaitez récupérer:

--SELECT *                                 don't
  SELECT ID, FName, LName, PhoneNumber  -- do
  FROM Emplopees;

(Lorsque vous effectuez des requêtes interactives, ces considérations ne s'appliquent pas.)


Cependant, SELECT * ne fait pas mal dans la sous-requête d'un opérateur EXISTS, car EXISTS ignore de toute façon les données réelles (il vérifie uniquement si au moins une ligne a été trouvée). Pour la même raison, il n'est pas utile de lister des colonnes spécifiques pour EXISTS, de sorte que SELECT * a plus de sens:

-- list departments where nobody was hired recently
SELECT ID,
       Name
FROM Departments
WHERE NOT EXISTS (SELECT *
                  FROM Employees
                  WHERE DepartmentID = Departments.ID
                    AND HireDate >= '2015-01-01');

En retrait

Il n'y a pas de norme largement acceptée. Tout le monde s'accorde sur le fait que tout faire en une seule ligne est mauvais:

SELECT d.Name, COUNT(*) AS Employees FROM Departments AS d JOIN Employees AS e ON d.ID = e.DepartmentID WHERE d.Name != 'HR' HAVING COUNT(*) > 10 ORDER BY COUNT(*) DESC;

Au minimum, mettez chaque clause dans une nouvelle ligne et séparez les lignes si elles deviennent trop longues sinon:

SELECT d.Name,
       COUNT(*) AS Employees
FROM Departments AS d
JOIN Employees AS e ON d.ID = e.DepartmentID
WHERE d.Name != 'HR'
HAVING COUNT(*) > 10
ORDER BY COUNT(*) DESC;

Parfois, tout ce qui suit le mot-clé SQL introduisant une clause est en retrait sur la même colonne:

SELECT   d.Name,
         COUNT(*) AS Employees
FROM     Departments AS d
JOIN     Employees AS e ON d.ID = e.DepartmentID
WHERE    d.Name != 'HR'
HAVING   COUNT(*) > 10
ORDER BY COUNT(*) DESC;

(Cela peut également être fait en alignant correctement les mots-clés SQL.)

Un autre style courant consiste à placer des mots-clés importants sur leurs propres lignes:

SELECT
    d.Name,
    COUNT(*) AS Employees
FROM
    Departments AS d
JOIN
    Employees AS e
    ON d.ID = e.DepartmentID
WHERE
    d.Name != 'HR'
HAVING
    COUNT(*) > 10
ORDER BY
    COUNT(*) DESC;

L'alignement vertical de plusieurs expressions similaires améliore la lisibilité:

SELECT Model,
       EmployeeID
FROM Cars
WHERE CustomerID = 42
  AND Status     = 'READY';

L'utilisation de plusieurs lignes rend plus difficile l'intégration de commandes SQL dans d'autres langages de programmation. Cependant, de nombreux langages ont un mécanisme pour les chaînes multi-lignes, par exemple @"..." en C #, """...""" en Python ou R"(...)" en C ++.

Joint

Les jointures explicites doivent toujours être utilisées. les jointures implicites ont plusieurs problèmes:

  • La condition de jointure se trouve quelque part dans la clause WHERE, mélangée à toute autre condition de filtre. Cela rend plus difficile de voir quelles tables sont jointes et comment.

  • En raison de ce qui précède, le risque d’erreurs est plus élevé et il est plus probable qu’elles soient retrouvées plus tard.

  • En SQL standard, les jointures explicites sont le seul moyen d'utiliser des jointures externes :

    SELECT d.Name,
           e.Fname || e.LName AS EmpName
    FROM      Departments AS d
    LEFT JOIN Employees   AS e ON d.ID = e.DepartmentID;
    
  • Les jointures explicites permettent d'utiliser la clause USING:

    SELECT RecipeID,
           Recipes.Name,
           COUNT(*) AS NumberOfIngredients
    FROM      Recipes
    LEFT JOIN Ingredients USING (RecipeID);
    

    (Cela nécessite que les deux tables utilisent le même nom de colonne.
    USING supprime automatiquement la colonne dupliquée du résultat, par exemple, la jointure dans cette requête renvoie une seule colonne RecipeID .)



Modified text is an extract of the original Stack Overflow Documentation
Sous licence CC BY-SA 3.0
Non affilié à Stack Overflow