NOT IN cache un piège sérieux : si la sous-requête qu'il utilise renvoie ne serait-ce qu'une seule valeur NULL, la requête entière ne renvoie plus aucune ligne — silencieusement, sans erreur.

Sur nos données actuelles, aucune ligne de commandes n'a de produit_id NULL, donc tout fonctionne normalement :

SELECT p.nom FROM produits p
WHERE p.id NOT IN (SELECT produit_id FROM commandes);

Cette requête renvoie bien Stylo et Biscuits (2 lignes), les mêmes produits jamais commandés que dans les deux leçons précédentes.

Mais si une seule ligne de commandes avait produit_id NULL (une commande sans produit renseigné), cette même requête ne renverrait plus rien du tout, pour aucun produit — y compris Stylo et Biscuits. La raison : id NOT IN (1, 3, 4, 6, NULL) revient à évaluer id <> 1 AND id <> 3 AND ... AND id <> NULL ; or comparer quoi que ce soit à NULL avec <> renvoie toujours « inconnu », ce qui rend l'ensemble du AND jamais vrai.

NOT EXISTS, vu à la leçon précédente, ne souffre pas de ce piège : il teste une existence ligne par ligne, sans jamais construire de liste globale de valeurs à exclure.

À retenir :

• NOT IN (sous-requête) devient silencieusement vide dès qu'une seule valeur NULL apparaît dans le résultat de la sous-requête.
• Ce piège ne produit aucune erreur visible : la requête s'exécute normalement mais renvoie 0 ligne, ce qui peut passer inaperçu.
• NOT EXISTS est la façon sûre d'exprimer la même idée, insensible à la présence de NULL dans la sous-requête.

À vous de jouer : si commandes gagnait une ligne avec produit_id NULL, réécrivez la requête NOT IN ci-dessus en NOT EXISTS pour la rendre à nouveau fiable.