9 bonnes pratiques pour écrire des requêtes SQL

Si vous lisez cet article, vous êtes probablement déjà familiarisé avec SQL. Vous savez écrire des requêtes SQL de base. Il existe de nombreuses façons d'exécuter une requête SQL pour obtenir les résultats souhaités sur votre base de données.

Cependant, toutes les requêtes SQL ne sont pas égales. La plupart peuvent être optimisés pour suivre les meilleures pratiques de requête SQL. Cet article se concentre sur 9 conseils d'optimisation des requêtes SQL. Après lecture, vous connaîtrez toutes les choses à faire et à ne pas faire pour écrire des requêtes SQL.

1. **Évitez l'utilisation de l'astérisque SELECT (SELECT *)**

C'est l'une des meilleures pratiques SQL les plus importantes. La requête SELECT * renvoie les enregistrements de toutes les colonnes de la table. Bien qu'utile dans certains cas, cette requête produit souvent de nombreuses complications :

Vous n'aurez peut-être pas besoin de récupérer toutes les colonnes. Cependant, SELECT * les renvoie tous, consommant une bande passante excessive pour exécuter une requête sur le réseau.
Les noms de colonne d'un tableau peuvent être modifiés ou supprimés, et de nouvelles colonnes peuvent être ajoutées. Ainsi, vous pourriez recevoir des résultats inattendus pour la requête SELECT *. Spécifier des noms de colonne est une meilleure idée.
SELECT * est plus lent que SELECT Column Names car ce dernier peut utiliser des index de colonne pour renvoyer des données.
L'ordre des colonnes renvoyé par SELECT * n'est pas sous votre contrôle. Cependant, vous définissez l'ordre souhaité lorsque vous spécifiez les noms de colonne.

2. Utilisez les clauses WHERE et HAVING avec précision

Les clauses WHERE et HAVING en SQL ont des fonctionnalités différentes. Par conséquent, nous devrions les utiliser différemment. Les trois principaux cas d'utilisation de WHERE et HAVING sont les suivants :

WHERE peut être utilisé avec les requêtes CRUD, c'est-à-dire SELECT, INSERT, UPDATE, DELETE. D'un autre côté, vous pouvez utiliser HAVING uniquement avec l'instruction SELECT.
WHERE filtre les données avant toute opération d'agrégation telle que GROUP BY. Ensuite, il peut être utilisé sans aucune fonction d'agrégation. HAVING doit être utilisé après l'agrégation.
Nous pouvons utiliser les fonctions d'agrégation, telles que SUM, MIN, MAX COUNT avec la clause HAVING. Avec la clause WHERE, nous ne pouvons pas utiliser les fonctions d'agrégation, sauf si cette clause fait partie d'une sous-requête contenue par la clause HAVING.

3. Utilisez la requête INNER JOIN au lieu de la clause WHERE pour joindre des tables

La requête JOIN est probablement l'une des requêtes SQL les plus utiles. Il vous permet de SÉLECTIONNER des données à partir de plusieurs tables. Bien que vous puissiez utiliser la clause WHERE pour obtenir des données agrégées à partir de deux tables, la clause WHERE est très inefficace.

La clause WHERE renvoie CROSS JOIN qui est un produit cartésien des enregistrements dans les deux colonnes. Par exemple, si vous avez 1 000 enregistrements dans la table A et le même nombre d'enregistrements dans la table B, la clause WHERE créera un CROSS JOIN avec 1 000 x 1 000 =1 000 000 enregistrements.

Si les colonnes des tables A et B impliquées dans la clause WHERE n'ont que 1 000 valeurs communes, la clause WHERE renverra 1 000 enregistrements à partir des 1 000 000 d'enregistrements initiaux créés par le produit cartésien.

La clause INNER JOIN renvoie uniquement 1 000 enregistrements où les deux tables A et B ont des valeurs communes dans les colonnes. Dans ce cas, INNER JOIN a 1 000 fois moins de travail que la clause WHERE.

Certaines bases de données convertissent la clause WHERE de la requête JOIN en clause INNER JOIN en arrière-plan. Cependant, il est toujours recommandé d'utiliser explicitement INNER JOIN au lieu de la clause WHERE pour suivre les meilleures pratiques de codage SQL.

4. Utilisez EXISTS, NOT EXISTS au lieu de IN et NOT IN en SQL

Utilisez toujours EXIST sur la clause IN si vous souhaitez confirmer l'existence d'une valeur dans une table particulière.

Le processus qui exécute la clause EXISTS s'arrête dès qu'il trouve la valeur requise dans la table. D'autre part, la requête IN analyse tout même après avoir trouvé la valeur nécessaire.

De la même manière, vous devez toujours utiliser NOT EXISTS au lieu de NOT IN lorsque vous recherchez la valeur qui n'existe pas dans une table.

5. Utilisez l'opérateur égal à (=) au lieu de LIKE Opérateur en SQL

Vous pouvez utiliser les opérateurs =et LIKE pour faire correspondre les chaînes. La principale différence entre les deux est que l'opérateur LIKE est utilisé pour faire correspondre des caractères génériques tels que % à la recherche de chaînes partielles, tandis que l'opérateur égal "=" recherche des correspondances exactes.

Si vous devez choisir entre les deux, préférez toujours l'opérateur égal (« =»), car il utilise des colonnes indexées. Elle est donc plus rapide que la clause LIKE.

6. Utilisez la clause LIMIT pour réduire les résultats de recherche

Si vous devez renvoyer des données à partir de plusieurs tables ou colonnes, utilisez la clause LIMIT (également appelée clause TOP) pour réduire les résultats de la requête. S'il y a des milliers de colonnes, ou si vous voulez voir à quoi ressemblent les données dans vos tables uniquement, il n'est pas nécessaire de renvoyer toutes les lignes. Au lieu de cela, limitez le nombre de lignes renvoyées par la requête SELECT à l'aide de la clause LIMIT en conjonction avec elle.

7. Utiliser des alias de table lors de l'interrogation de plusieurs tables

Pour éviter toute confusion et empêcher les bases de données d'analyser les noms de colonne lors de la recherche de la table à laquelle elles appartiennent, utilisez toujours des alias de table.

Vous devez déjà utiliser des noms/alias de table si vous avez les mêmes noms de colonne dans plusieurs tables, cela n'augmentera donc pas votre charge de travail.

8. Évitez de préfixer les procédures stockées avec "sp_"

Si vous avez travaillé avec des procédures stockées, alors, très probablement, vous avez préfixé le nom de la procédure stockée avec "sp_". Ce n'est pas le meilleur.

SQL Server commence par rechercher les procédures stockées avec « sp_ » au début de leur nom dans la base de données principale avant de poursuivre la recherche ailleurs.

Par conséquent, vous pouvez gagner beaucoup de temps en ne préfixant pas les procédures stockées avec "sp_". Ensuite, au lieu d'essayer de localiser la procédure stockée dans la base de données principale, le serveur SQL vérifiera directement dbo en tant que propriétaire de la procédure stockée.

9. Adoptez un bon style d'écriture de requête

Il est essentiel de suivre les meilleures pratiques pour les requêtes SQL, telles que les bonnes pratiques de style lors de l'écriture de requêtes SQL. Faites attention aux recommandations ci-dessous pour améliorer votre style d'écriture de requête :

Ajoutez toujours des commentaires aux requêtes SQL. Les commentaires aideront non seulement les autres membres de l'équipe à mieux comprendre vos requêtes, mais vous rappelleront également ce que vous faisiez vous-même dans le passé.
Utilisez des conventions de dénomination évidentes. La base de données, les tables, les noms de colonnes, les tables temporaires et les autres noms de variables doivent être lisibles et clairs à 100 %.
Indentez vos requêtes dans la mesure du possible. Les requêtes internes doivent être en retrait d'un onglet à partir de la gauche. Les noms et types de colonnes à l'intérieur d'un tableau doivent également être en retrait. L'indentation garantit une apparence plus nette et améliore la lisibilité des requêtes, comme le reflètent les bonnes pratiques SQL Server pour les requêtes.

Conclusion

SQL est un langage très flexible offrant de nombreuses façons d'effectuer les tâches souhaitées sur une base de données. Pour rendre vos applications plus efficaces et productives et éviter les problèmes de base de données à long terme, appliquez les meilleures pratiques modernes d'optimisation des requêtes SQL pour écrire vos requêtes. Ces méthodes vous aident à accélérer le réglage des performances dans SQL, à éliminer les routines inutiles et à rendre tout votre travail plus concis et transparent.