SQL
Nettoyer le code en SQL
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 colonneRecipeID
.)