Retour à la liste des articles Articles
8 minutes de lecture

Comment organiser les requêtes SQL lorsqu'elles deviennent longues

La première longue requête SQL que vous aurez à traiter sera probablement difficile à structurer et à comprendre pour vous. Ces cinq conseils vous apprendront la meilleure façon d'organiser les requêtes SQL, c'est-à-dire de les écrire et de les formater.

Comme nous le savons tous, les requêtes SQL sont essentielles à la gestion des bases de données. Sans elles, il serait extrêmement difficile de trouver et de travailler avec les informations contenues dans une base de données.

La longueur des requêtes dépend du type d'informations dont nous avons besoin et de la taille de la base de données. Lorsque nous lisons un simple morceau de code SQL, nous sommes généralement capables de le comprendre assez facilement. Mais qu'en est-il si nous avons affaire à une requête de 1 500 lignes ? Si nous voulons comprendre ce que nous avons fait (ou le faire comprendre aux autres), nous devons savoir comment organiser les requêtes SQL. Heureusement, la mémorisation de cinq conseils utiles vous aidera à gérer toutes les longues requêtes SQL que vous écrirez. .

Comment organiser les requêtes SQL

Conseil 1 : mettez votre code en retrait

L'indentation aide à garder votre longue requête SQL propre en identifiant où chaque bloc de code commence. Cela rend la structure du programme plus compréhensible et permet aux développeurs de trouver facilement une instruction spécifique. Lorsque vous indentez correctement votre code, vous pouvez rapidement voir ce que vous sélectionnez, quelles tables fournissent les données et quelles restrictions s'y appliquent (c'est-à-dire les clauses WHERE et GROUP BY ).

Voyons un exemple de requête SQL relativement longue :

SELECT column1
       ,column2
FROM table1
WHERE column3 IN
(
    SELECT TOP(1) column4
    FROM table2
    INNER JOIN table3
    ON table2.column1 = table3.column1
)

Comparez le code ci-dessus à cet exemple :

SELECT column1, column2 FROM table1 WHERE column3 IN ( SELECT TOP(1) column4 FROM table2 INNER JOIN table3 ON table2.column1 = table3.column1)

Maintenant, imaginez qu'il y a aussi 100 instructions similaires. Sans indentation, un exemple de requête SQL aussi long sera très difficile à lire et à comprendre !

Il n'existe pas de style d'indentation unique. Chaque entreprise ou programmeur développe généralement le sien. Néanmoins, votre style d'indentation doit être compréhensible pour les autres. Pour vous aider à démarrer, j'ai fourni des liens vers des guides de style par ApexSQL et Simon Holywell.

L'indentation est la première chose que vous devez faire lorsque vous commencez à écrire du code. Si vous héritez d'un morceau de code sans indentation, il existe de nombreux sites qui vous permettent de formater gratuitement votre longue requête SQL.

Conseil 2 : utilisez la clause WITH

La clause WITH vous permet de nommer un bloc de sous-requêtes et de le traiter comme une table normale. Dans ce cas, la clause WITH remplace en fait une sous-requête normale.

Regardez l'exemple de requête SQL longue ci-dessous. Sa tâche est de montrer le nombre d'hôpitaux de Los Angeles où les patients dont la dernière visite remonte à plus de 14 jours ont reçu une dose moyenne de médicament supérieure à 1 000 unités.

WITH patient_data AS (
	SELECT patient_id, patient_name, hospital, drug_dosage
	FROM hospital_registry
	WHERE (last_visit > now() - interval '14 days' OR last_visit IS NULL) 
	AND city = "Los Angeles"
)

WITH average_dosage AS (
	SELECT hospital, AVG(drug_dosage) AS Average
	FROM patient_data
	GROUP BY hospital
)

SELECT count(hospital) 
FROM average_dosage;
WHERE AVG(drug_dosage) > 1000

Je vais expliquer tous les éléments de cette requête.

Le premier élément est la clause WITH. En l'utilisant, nous pouvons spécifier deux sous-requêtes comme patient_data et average_dosage et les utiliser comme des tables normales. La sous-requête patient_data a été utilisée pour créer la sous-requête average_dosage. Ainsi, average_dosage devient la source de données finale de l'instruction SELECT.

Cet arrangement est beaucoup plus propre que de tout écrire dans une seule requête et de mettre toutes les sous-requêtes dans les instructions WHERE.

Parce qu'elle rend le code plus facile à lire, la clause WITH est sans doute la meilleure façon d'organiser les requêtes SQL.

Conseil n° 3 : expliquez-vous avec des commentaires

Le code dit comment, mais les commentaires expliquent pourquoi. Les commentaires font partie des éléments utiles les plus importants de tout code, qu'il s'agisse d'un projet de programmation en Java ou d'une requête SQL. Ils permettent aux programmeurs d'exprimer leur processus de réflexion et les résultats qu'ils souhaitent obtenir.

Ajoutez toujours des commentaires à votre code. Vous serez heureux de l'avoir fait, tout comme les autres programmeurs qui travaillent sur votre SQL. Même si vous ne faites qu'une pause, ajoutez des commentaires - ils vous aideront à reprendre là où vous vous êtes arrêté.

Voici à quoi ressemble une requête SQL très simple sans commentaires :

SELECT name, 
      student_group,
FROM course_marks
WHERE points < 300 OR points IS NULL;

Savez-vous vraiment ce que signifie exactement le site WHERE? Sans commentaires, il est difficile de comprendre ce que le codeur voulait accomplir.

Si vous vous demandez comment organiser au mieux les requêtes SQL, prenez l'habitude de laisser des commentaires dans votre code. Voyons cette même longue requête SQL, mais avec des commentaires et des explications :

/*Get the list of every student 
who failed or was absent on exam*/

SELECT name, 
      student_group,
FROM course_marks
WHERE points < 300 OR points IS NULL; --student fails when gets 300 or less points.
--When student was absent, instead of points there is NULL in column

C'est mieux, n'est-ce pas ? Ces commentaires ont expliqué les actions du développeur et nous ont aidés à comprendre ce que fait la requête.

Conseil 4 : divisez les requêtes en étapes

Une longue requête SQL est en fait une collection de blocs de code, qui sont beaucoup plus faciles à contrôler et à vérifier pour détecter les erreurs. Construire votre requête étape par étape est une bonne pratique pour le développement SQL. Cela vous permettra de trouver les erreurs logiques plus rapidement et d'être plus sûr de vos résultats.

Regardez comme il est plus facile de comprendre cet exemple de longue requête SQL parce qu'elle a été divisée en étapes logiques :

WITH subject AS (
 SELECT 
 student_id, 
 subject_id,
 school_id,
 sum(exam_score) AS total_score 
 FROM subject_marks 
 GROUP BY student_id, subject_id, school_id
), 

student AS (
 SELECT 
 student_id,
 school_id,
 avg(total_score) AS average_student 
 FROM subject
 GROUP BY student_id, school_id
)

SELECT 
school_id, 
 avg(average_student) 
FROM student 
GROUP BY school_id;

Nous voulons que le résultat de cette requête nous montre le nombre moyen de points pour chaque élève de chaque école. La première étape (la clause WITH subject ) trouve la somme des points pour chaque matière. La deuxième étape (la clause WITH student ) calcule la moyenne des points pour chaque élève. Lorsque nous atteignons la clause SELECT, il ne nous reste plus qu'à trouver le nombre moyen de points et à regrouper les résultats par école.

En construisant une longue requête SQL de cette manière, vous écrivez en fait une requête qui n'est plus très longue ni compliquée. Tout dépend simplement de la façon dont vous choisissez de la décomposer.

Conseil n° 5 : conservez une convention de dénomination

Il est également très important d'utiliser une seule convention de dénomination pour les tables, les colonnes et les requêtes. Le code SQL est ainsi plus facile à écrire et à lire.

Lorsqu'une ancienne base de données comporte des tables nommées PRODUCT, users, USERS_other et UserSECOND_NEW, l'aspect n'est pas très professionnel et le codage devient chaotique. Respectez les règles établies pour les majuscules, les traits de soulignement, les espaces, etc. Cela s'applique également aux styles de requête : respectez les mêmes règles de formatage et les mêmes modèles d'indentation pour l'ensemble de la base de données. Si vous commencez une nouvelle ligne après un SELECT, faites-le à chaque fois, surtout lorsque vous écrivez une longue requête SQL.

Les conventions de nommage peuvent être très différentes d'une base de données à l'autre. Comme pour l'indentation, il n'existe pas de style unique reconnu par l'industrie. Je vous recommande de trouver les conventions les plus largement utilisées et de modeler votre propre style sur celles-ci. Ces articles dans les blogs Vertabelo et Launch by Lunch constituent un bon point de départ.

La meilleure façon de comprendre la différence entre un bon et un mauvais style de requête est de les voir par vous-même. Ci-dessous, nous trouvons un exemple de mauvais style :

SELECT name, SECONDNAME, Date_TIME, address, SecondAddress
FROM registry, other_USERSData
WHERE registry.id = other_USERSData.id;

Cette requête, qui utilise un style constant, est beaucoup plus lisible :

SELECT name, second_name, date_time, address, second_address
FROM registry, other_users_data
WHERE registry.id = other_users_data.id;

La mystérieuse longue requête SQL - Résumé

En résumé, ces conseils vous aideront à écrire de meilleures requêtes, quelle que soit leur longueur, mais il est particulièrement important de les appliquer chaque fois que vous écrivez une longue requête SQL. La meilleure chose que vous puissiez faire est de vous entraîner à utiliser les bonnes techniques. Si vous ne savez pas comment développer vos compétences, notre site Web SQL pour les débutants cours est une excellente solution. Il existe un grand nombre de leçons qui vous apprendront à organiser les requêtes SQL.

Il vous faudra du temps pour apprendre à écrire des requêtes SQL propres et intelligentes. Vous devrez comprendre les relations entre les tables, la planification du code et des données, la manière d'identifier les parties d'une requête et les résultats que vous pouvez attendre. Patience et travail acharné sont les clés du succès !