La combinaison parfaite : explication des jointures SQL

Toutes les invitations ne mènent pas à une combinaison parfaite, et il en va de même en SQL. Cet article explique les jointures SQL à l'aide d'un exemple de liste d'invités à une fête, vous aidant à comprendre comment les différents types de jointures déterminent les enregistrements qui apparaissent dans le résultat.

Février est le mois de l'amour. Les applications de rencontre parlent de correspondances, les invitations pour les événements de la Saint-Valentin sont envoyées et tout le monde espère que les choses se passeront comme prévu.

En SQL, nous avons constamment affaire à des correspondances, mais d'une manière plus pratique. Les données sont souvent réparties sur plusieurs tables. Pour les analyser, nous devons combiner les tables en fonction des valeurs correspondantes. C'est exactement ce que font les jointures. Elles relient les lignes de différentes tables à l'aide d'une colonne commune et déterminent les enregistrements qui apparaissent ensemble dans le résultat.

Pour les débutants, cela peut sembler abstrait au premier abord. Des termes tels que INNER JOIN ou LEFT JOIN décrivent des règles précises, mais sans image claire, il est facile de perdre de vue ce qui se passe réellement.

Maîtrisez l'art de la correspondance
Si vous voulez éviter les conjectures et commencer à rédiger des requêtes comme un pro, le cours Les jointures en SQL sur LearnSQL.fr est fait pour vous. Avec 93 exercices pratiques, il est conçu pour vous faire passer de « C'est compliqué » à « Expert SQL » à l'aide de scénarios réels. C'est le moyen le plus rapide de maîtriser les JOIN.

Dans cet article, nous utiliserons une métaphore simple sur la Saint-Valentin pour expliquer l'Les jointures en SQL de manière claire et intuitive.

Le contexte

Imaginez que vous organisez une fête. Il peut s'agir d'un événement pour la Saint-Valentin, d'une fête pour célibataires ou simplement d'une réunion informelle — les détails n'ont pas vraiment d'importance.

Avant la fête, vous créez une liste des personnes que vous avez invitées. La fête a lieu, et après coup, vous pouvez voir ce qui s'est réellement passé :

• certaines personnes invitées se sont présentées
• certaines personnes invitées ne se sont pas présentées
• et quelques personnes se sont présentées même si elles n'étaient pas invitées

Vous vous retrouvez donc avec une deuxième liste : les personnes qui ont assisté à la fête. Vous avez désormais deux listes :

• les personnes qui ont été invitées
• les personnes qui se sont présentées

En termes SQL, cela nous donne deux tables. Une table stocke les personnes qui ont été invitées à la fête, créée avant l'événement. La deuxième table stocke les personnes qui ont réellement assisté à la fête, en fonction de ce qui s'est réellement passé. Certains enregistrements apparaissent dans les deux tables, d'autres n'apparaissent que dans une seule. Les Les jointures en SQLs nous aident à comparer ces tables et à décider quels enregistrements nous voulons voir ensemble dans le résultat.

invited

showed_up

Alice et Carol ont été invitées et se sont présentées.
Bob et Dave ont été invités mais n'ont pas assisté à la fête.
Eve s'est présentée sans invitation.

La comparaison de ces deux listes donne des réponses différentes, selon ce que vous souhaitez savoir.

INNER JOIN : les personnes qui ont été invitées et qui se sont présentées ❤️

Une INNER JOIN est la manière la plus courante de combiner des tables. Elle recherche la « correspondance parfaite » entre vos deux listes. Dans notre scénario de fête, elle renvoie uniquement les personnes qui :

1. Figuraient sur la liste d'invited.
2. ET qui ont effectivement été invitées.

Si quelqu'un a été invité mais n'est pas venu (comme Bob), il est exclu. Si quelqu'un s'est présenté mais ne figurait pas sur la liste (comme Eve), il est également exclu. Seules les « correspondances » qui se recoupent sont retenues.

Voici un conseil de pro pour les débutants : INNER JOIN est la norme. Dans les bases de données SQL, si vous écrivez simplement JOIN, la base de données suppose que vous voulez dire INNER JOIN. C'est le paramètre « par défaut » pour les relations entre les données, car la plupart du temps, nous voulons uniquement voir les enregistrements où les deux côtés concordent.

Nous pouvons maintenant écrire un INNER JOIN qui renvoie uniquement les invités qui ont assisté à l'événement :

SELECT
  i.id,
  i.name,
  i.email,
  s.arrived_at
FROM invited AS i
INNER JOIN showed_up AS s
  ON i.id = s.id
ORDER BY s.arrived_at;

Résultat

Alice et Carol apparaissent car leur id existe dans les deux tables. Bob et Dave sont exclus car ils ne se sont pas présentés. Eve est exclue car elle n'était pas invitée, il n'y a donc pas de ligne correspondante dans la liste des invités.

Dans la réalité, INNER JOIN répond à des questions telles que :

• Quels utilisateurs invités se sont connectés ?
• Quels clients ont passé une commande ?
• Quels e-mails ont été envoyés et ouverts ?

S'il n'y a pas de correspondance des deux côtés, l'enregistrement n'apparaît tout simplement pas dans le résultat.

LEFT JOIN : toutes les personnes qui ont été invitées 💌

Une jointure gauche (LEFT JOIN) commence par la table d'inviteds. Cela signifie que toutes les personnes invitées apparaissent dans le résultat, qu'elles se soient présentées ou non.

• Si quelqu'un s'est présenté, vous voyez ses données de présence.
• si elle n'est pas venue, les colonnes de la showed_up tableau contiennent la valeur NULL. NULL Cela signifie simplement qu'aucun enregistrement correspondant n'a été trouvé.

Voici un LEFT JOIN qui montre toutes les personnes invitées, ainsi que leur heure d'arrivée si elles ont assisté à l'événement :

SELECT
  i.id,
  i.name,
  i.email,
  s.arrived_at
FROM invited AS i
LEFT JOIN showed_up AS s
  ON i.id = s.id
ORDER BY i.id;

Résultat

Bob et Dave apparaissent dans le résultat même s'ils n'étaient pas présents. Le NULL indique simplement qu'aucune ligne correspondante n'a été trouvée dans la showed_up table.

En pratique, LEFT JOIN est utile lorsque vous voulez demander :

• Qui avons-nous invité, même s'ils ne sont pas venus ?
• Quels utilisateurs se sont inscrits mais ne se sont jamais connectés ?
• Quels clients n'ont jamais passé de commande ?

C'est pourquoi LEFT JOIN est l'un des JOIN les plus couramment utilisés dans les rapports et les analyses.

Conseil de pro : la jointure « sûre »

Dans le monde professionnel, LEFT JOIN est souvent le choix « incontournable » pour les rapports. Pourquoi ? Parce qu'il est sûr. Il garantit que vous ne « supprimez » pas accidentellement des personnes de votre rapport simplement parce qu'elles n'ont pas encore effectué d'action. Si vous souhaitez obtenir une liste de tous les clients et de leurs commandes, un LEFT JOIN garantit que même les clients qui n'ont encore rien acheté sont pris en compte.

RIGHT JOIN : toutes les personnes qui se sont présentées 🤷

Une RIGHT JOIN fonctionne de la même manière qu'une LEFT JOIN, mais de l'autre côté. Il commence par la showed_up liste au lieu de la invited liste. Cela signifie que

• chaque personne qui est venue à la fête apparaît dans le résultat
• si elle a été invitée, vous voyez les détails de son invitation
• si elle ne l'était pas, les colonnes d'invitation contiennent NULL

Cela inclut naturellement les personnes qui se sont présentées sans invitation.

Voici un RIGHT JOIN qui montre toutes les personnes qui se sont présentées, qu'elles aient été invitées ou non :

SELECT
  s.id,
  i.name,
  i.email,
  s.arrived_at
FROM invited AS i
RIGHT JOIN showed_up AS s
  ON i.id = s.id
ORDER BY s.arrived_at;

Résultat

Eve apparaît dans le résultat même si elle n'était pas invitée. Les NULL valeurs dans les colonnes d'invitation signifient simplement qu'il n'y avait pas d'enregistrement correspondant dans la invited table.

RIGHT JOIN est moins courant dans la pratique, car vous pouvez généralement le réécrire en LEFT JOIN en changeant l'ordre des tables. Néanmoins, comprendre son fonctionnement vous aide à lire et à comprendre le code SQL écrit par d'autres.

FULL OUTER JOIN : le rapport complet sur la fête 💝

Une jointure externe complète (FULL OUTER JOIN) affiche tout. Elle combine les deux tableaux et conserve tous les enregistrements des deux côtés, qu'il y ait une correspondance ou non.

Cela signifie que vous voyez :

• les personnes qui ont été invitées et qui se sont présentées
• les personnes qui ont été invitées mais qui ne sont pas venues
• les personnes qui se sont présentées sans invitation

Rien n'est filtré.

Voici un FULL OUTER JOIN qui produit le rapport complet de la fête :

SELECT
  i.id AS invited_id,
  i.name,
  i.email,
  s.arrived_at
FROM invited AS i
FULL OUTER JOIN showed_up AS s
  ON i.id = s.id
ORDER BY i.id, s.id;

Résultat

Ce résultat montre toute l'histoire :

• Alice et Carol ont été invitées et se sont présentées
• Bob et Dave ont été invités mais n'ont pas assisté à la fête
• Eve s'est présentée sans invitation

FULL OUTER JOIN est utile lorsque vous souhaitez avoir une vue d'ensemble et ne voulez perdre aucun enregistrement des deux tables. Il est particulièrement utile pour les audits, les vérifications de données et les rapports de haut niveau, où les données manquantes sont tout aussi importantes que les données correspondantes.

Mêmes données, questions différentes

La chose la plus importante à retenir concernant l'Les jointures en SQL, c'est que

Les données ne changent pas.
Seule la question change.

Lorsque vous passez d'un INNER JOIN à un LEFT JOIN ou un FULL OUTER JOIN, vous ne modifiez pas les tables. Vous ne changez que les règles qui déterminent quels enregistrements apparaissent dans le jeu de résultats.

Une fois que vous cessez de considérer les JOIN comme quelque chose de mystérieux et que vous commencez à les considérer comme des filtres appliqués à deux listes, ils deviennent beaucoup plus faciles à comprendre.

Ce changement de perspective est souvent le moment où les JOIN deviennent enfin compréhensibles pour les débutants.

Des invités à la fête aux tables SQL

L'exemple de la fête n'est qu'un moyen de rendre la logique visible. Le même schéma apparaît partout dans le travail SQL réel.

Par exemple :

• clients et commandes
• utilisateurs et identifiants
• e-mails envoyés et e-mails ouverts

Dans chaque cas, vous travaillez avec deux listes et posez des questions similaires :

• Qui apparaît dans les deux listes ?
• Qui apparaît uniquement d'un seul côté ?
• Qui est-ce que je souhaite inclure dans mon résultat, même s'il manque quelque chose ?

Les jointures en SQL existent pour répondre précisément à ces questions. Une fois que vous comprenez comment elles fonctionnent avec une simple liste d'invités, il devient facile d'appliquer la même logique à des tableaux réels.

Conclusion : choisissez la jointure qui correspond à la question

En SQL, comme en amour, il n'y a pas de « meilleure » correspondance unique. Il n'y a que la jointure qui correspond à la question que vous posez.

• Parfois, vous ne voulez que des correspondances confirmées et mutuelles (INNER JOIN).
• Parfois, vous avez besoin de voir qui n'a pas encore répondu (LEFT JOIN).
• Parfois, vous voulez avoir une image complète, désordonnée et magnifique de toutes les personnes impliquées (FULL OUTER JOIN).

Une fois que vous cessez de considérer les JOIN comme du code abstrait et que vous commencez à les voir comme la logique des relations, vous libérez la véritable puissance des bases de données relationnelles.

Comprendre la théorie est un excellent premier rendez-vous, mais la maîtrise vient de la pratique. Si vous souhaitez cesser de remettre en question votre syntaxe et commencer à rédiger des requêtes complexes en toute confiance, le cours «Les jointures en SQL» est la prochaine étape idéale. Vous dépasserez la liste des invités et travaillerez avec des ensembles de données professionnels, développant ainsi la mémoire musculaire dont vous avez besoin pour une carrière dans le domaine des données.

Et si vous êtes prêt à vous engager dans une relation sérieuse et durable avec votre carrière, le pack SQL « Tout à vie » vous donne un accès à vie à tous les cours que nous proposons, des requêtes de base à l'analyse avancée des données. C'est le cadeau ultime à offrir à votre futur moi.

Ne laissez pas vos données rester « compliquées ». Commencez dès aujourd'hui votre parcours vers la combinaison parfaite.