Retour à la liste des articles Articles
9 minutes de lecture

Comment lire les requêtes SQL d'autres personnes sans se perdre

Ouvrir le SQL de quelqu'un d'autre peut rapidement prêter à confusion. Il suffit d'un coup d'œil aux JOIN, aux alias et aux filtres pour se sentir perdu. Voici comment décomposer toute requête étape par étape et la comprendre.

Lire votre propre SQL est une chose. Lire la requête de 200 lignes de quelqu'un d'autre qui alimente un tableau de bord clé en est une autre.

Cet article vous montrera comment aborder le SQL d'autres personnes étape par étape, afin que vous puissiez comprendre ce qu'il fait, repérer les problèmes et vous sentir à l'aise pour apporter des modifications. Il est destiné aux débutants et aux analystes juniors qui connaissent déjà les bases, mais qui se sentent encore dépassés par les requêtes « réelles ».

Si vous débutez et avez besoin d'une base solide, il est très utile de suivre d'abord un parcours structuré, commeLearnSQL.fr le cours SQL pour les débutants de et le parcours SQL de A à Z. Ils vous fournissent le vocabulaire ; cet article vous montre comment « lire les longues phrases » écrites par d'autres.

Pourquoi est-il si difficile de lire du SQL écrit par d'autres ?

Une requête SQL longue peut sembler plus difficile à comprendre que du code dans d'autres langages, car :

  • Tout le monde utilise des habitudes de formatage et de nommage différentes.
  • Certains codes sont écrits par des personnes, d'autres par des outils qui génèrent du SQL.
  • La requête se trouve souvent dans un rapport, un tableau de bord ou un processus ETL que vous ne connaissez pas encore parfaitement.
  • Vous ne pouvez pas voir le modèle de données en un seul endroit ; vous devez le déduire à partir des noms des tables et des colonnes.

La bonne nouvelle : il existe une méthode reproductible pour « décoder » ces requêtes. Vous n'avez pas besoin de mathématiques avancées, juste d'une approche minutieuse, étape par étape.

Étape 1 : commencez par l'objectif, pas par la syntaxe

Avant d'examiner les mots-clés, posez-vous une question simple : à quoi cette requête tente-t-elle de répondre ?

Vous pouvez souvent le deviner à partir du contexte :

  • Le nom du rapport ou de l'onglet du tableau de bord.
  • Le nom du fichier ou de la vue (par exemple : daily_revenue_summary, churn_risk_scores).
  • L'endroit où la requête est utilisée (rapport marketing hebdomadaire, rapprochement financier, analyse de produit, etc.

Si vous ne savez pas, demandez à un collègue ou consultez la documentation. Lire une requête sans connaître la question qui la sous-tend revient à lire la solution d'une énigme sans connaître l'énigme.

Une fois que vous avez une idée (« Cela calcule probablement les revenus par canal et par jour »), vous pouvez vérifier plus tard si votre lecture de la requête correspond à cela.

Étape 2 : Nettoyez la requête afin d'en voir la forme

Une mise en page désordonnée rend toute requête plus difficile à comprendre. Vous n'avez pas besoin d'être doué pour le formatage manuel pour améliorer cela.

Travaillez sur une copie de la requête (afin de ne pas endommager le code de production) et effectuez une ou plusieurs des opérations suivantes :

  • Utilisez l'option « Formater SQL » de votre éditeur, si elle existe.
  • Collez la requête dans un formateur SQL en ligne.
  • Ajoutez vous-même des sauts de ligne de base :
  • Placez chaque mot-clé principal sur une ligne distincte : SELECT, FROM, JOIN, WHERE, GROUP BY, HAVING, ORDER BY.
  • Placez chaque colonne sélectionnée sur une ligne distincte.
  • Placez chaque JOIN sur une nouvelle ligne.

Après cela, vous devriez pouvoir voir les blocs :

  • Un bloc extérieur SELECT
  • A FROM avec plusieurs JOINs
  • WHERE, GROUP BY, HAVING, ORDER BY sections

Cette séparation visuelle est essentielle. De nombreuxLearnSQL.fr exercices dans SQL Basics et les cours pratiques ultérieurs vous entraînent implicitement à repérer cette structure en vous exposant à des requêtes bien formatées.

Étape 3 : Reconstruisez le modèle de données dans votre tête

La plupart des confusions proviennent du fait de ne pas savoir ce que signifient les tables et les colonnes. Prenez le temps de vous y attarder, cela en vaut la peine.

3.1. Consultez les définitions des tables et des colonnes

Utilisez tous les outils à votre disposition :

  • Diagrammes de base de données (si votre équipe les utilise).
  • Vues système (par exemple, information_schema).
  • commandes « Décrire la table » (DESCRIBE, SHOW COLUMNS, etc.).
  • Documentation interne ou catalogue de données, si vous en disposez.

Pour chaque table clé de la requête, répondez aux questions suivantes :

  • Que représente une ligne ? (un client, une commande, un événement, une version de produit, etc.)
  • Quelles colonnes sont des identifiants (clés primaires, clés étrangères, clés métier telles que email, SKU, etc.) ?
  • Quelles colonnes sont des métriques ou des attributs (amount, status, created_at, country, etc.) ?

3.2. Dessinez rapidement un diagramme de jointure

Prenez une feuille de papier ou un tableau blanc et dessinez :

  • Une case pour chaque table (ou CTE) référencée dans la requête.
  • L'alias de la table entre parenthèses à côté du nom de la table (par exemple : customers (c)).
  • Des lignes entre les cases indiquant les JOIN conditions.

Ensuite, étiquetez chaque ligne avec les colonnes utilisées pour la jointure, par exemple : c.customer_id = o.customer_id.

Ce diagramme permet de répondre beaucoup plus facilement à la question suivante :

  • Quelle est la table « principale » ?
  • Quelles tables ajoutent simplement des attributs supplémentaires ?
  • Où peuvent apparaître des doublons ?

Étape 4 : Lisez la requête dans un ordre logique

Le langage SQL s'écrit de haut en bas, mais il ne s'exécute pas de cette manière dans votre tête. Voici un ordre simple qui fonctionne pour la plupart des requêtes :

  1. FROM et JOIN
  2. WHERE
  3. GROUP BY et HAVING
  4. SELECT liste (y compris les expressions et les fonctions de fenêtre)
  5. ORDER BY, LIMIT / TOP / OFFSET

Pour une requête avec des sous-requêtes :

  • Commencez par la sous-requête la plus interne.
  • Traitez chaque sous-requête comme une « étape » dans un pipeline.
  • Donnez à chaque étape une brève description en anglais simple.

Vous n'avez pas encore besoin de réécrire le SQL. Contentez-vous de construire un récit : « Nous sélectionnons d'abord les clients actifs, puis nous joignons leurs commandes, puis nous les regroupons par canal et par jour. »

C'est exactement le type de réflexion en plusieurs étapes que vous pratiquez dans les cours plusLearnSQL.fr avancés de , comme le cours sur les sous-requêtes.

Étape 5 : prêtez attention aux noms, aux alias et aux commentaires

Les alias cryptiques sont souvent source de confusion. Dans votre copie provisoire de la requête, vous êtes libre de les renommer pour votre propre compréhension.

Par exemple, remplacez :

FROM c AS t1
 JOIN o AS t2 ON t1.id = t2.customer_id

en quelque chose comme :

FROM customers AS c
 JOIN orders AS o ON c.id = o.customer_id

De même, dans la SELECT liste :

  • Essayez d'aligner les expressions et leurs alias.
  • Réécrivez les alias peu clairs dans vos notes :
  • total_amount_30d au lieu de t_amt
  • first_paid_date au lieu de d1

S'il y a des commentaires, lisez-les attentivement. Ils pourraient expliquer :

  • Pourquoi un filtre étrange existe.
  • Pourquoi un JOIN est utilisé.
  • Pourquoi une partie de la logique est conservée pour des raisons de compatibilité ascendante.

S'il n'y a pas de commentaires, rédigez-en vous-même, même si c'est uniquement pour vous. Un simple commentaire tel que :

-- Calculate revenue per customer per month, excluding internal test accounts

vous aidera, vous et les futurs lecteurs.

Étape 6 : Demandez de l'aide à bon escient (y compris ChatGPT)

Parfois, vous pouvez encore vous retrouver bloqué, même après avoir suivi toutes ces étapes. C'est normal.

Options :

  • Demandez à un collègue qui a rédigé ou qui gère la requête.
  • Demandez à un analyste senior ou à un ingénieur de données de valider votre compréhension.

Utilisez des outils tels que ChatGPT pour expliquer certaines parties de la requête, dans des conditions strictes :

  • Ne collez pas de données confidentielles, de clés API ou de noms de clients.
  • Supprimez ou anonymisez les noms de tables et de colonnes qui révèlent des informations sensibles.
  • Ne collez que la structure pour laquelle vous avez besoin d'aide (par exemple, une requête spécifique CTE, et non l'ensemble du pipeline).

Posez des questions ciblées :

  • « Que fait cette fonction fenêtre ? »
  • « Quelles lignes survivront à cette jointure et à ce filtre ? »
  • « La logique GROUP BY est-elle cohérente avec la liste SELECT ? »

Considérez l'IA comme un outil supplémentaire dans votre boîte à outils, similaire à un formateur ou à un visualiseur de requêtes. Elle doit soutenir votre raisonnement, et non le remplacer.

Comment mettre cette compétence en pratique

Lire le code SQL d'autres personnes est une compétence que vous pouvez mettre en pratique, et pas seulement quelque chose qui vous arrive au travail.

Quelques idées :

  • Prenez d'anciennes requêtes dans le dossier de rapports de votre équipe et procédez à une « ingénierie inverse » :
    • Quelle était la question commerciale ?
    • Quelles tables sont concernées ?
    • Comment décririez-vous la requête en trois lignes ?

Dans votre propre travail :

  • Laissez des commentaires plus pertinents que ceux dont vous avez hérité.
  • Utilisez des alias clairs et des noms significatifs.
  • Formatez vos requêtes de manière cohérente.

Sur LearnSQL.fr:

  • Suivez le parcours SQL de A à Z pour voir des requêtes plus complexes mais bien structurées.
  • Utilisez SQL avancédes « exercices de lecture » : ne vous contentez pas d'écrire des réponses, lisez et expliquez également les solutions types.

Plus vous verrez de requêtes, moins la suivante vous fera peur. Vous commencerez à reconnaître des schémas et à vous dire : « Ah, c'est comme ce rapport sur les revenus, mais avec une dimension supplémentaire et un filtre légèrement différent. »

Conclusion

Il n'est pas nécessaire d'être un ingénieur de données senior pour comprendre les longues requêtes SQL écrites par d'autres. Il suffit d'avoir une méthode.

Si vous cherchez un endroit où mettre en pratique ces compétences et acquérir une réelle confiance en SQL, découvrez le pack SQL Tout à vie de LearnSQL.fr. Il vous donne un accès à vie à tous les cours, des bases du SQL aux exercices avancés, afin que vous puissiez renforcer vos connaissances fondamentales, apprendre des techniques plus approfondies et traiter facilement des requêtes complexes.