Disons que pour simplifier, il conviendrait d'utiliser un modèle de données plus standard avec, outre des clés primaires dans chaque tables, une clé étrangère lorsque c'est approprié. De cette manière, les jointure seront beaucoup plus facile à concevoir.
Les deux requêtes en une seule... j'essaye de comprendre le résultat recherché, mais à vue de nez, si je ne fais pas erreur, ça pourrait ressembler à quelque chose du style :
...
FROM t
INNER JOIN t0 ON t.champ1 = t0.champ1
AND t.champ2 NOT IN(
SELECT DISTINCT t0.champ2
FROM t0
)
...
Ou encore :
...
FROM t
INNER JOIN t0 ON t.champ1 = t0.champ1
WHERE t.champ2 NOT IN(
SELECT DISTINCT t0.champ2
FROM t0
)
...
Note à propos des clés primaires : je déconseille d'utiliser des colones de données « signifiantes » comme clé primaire. La clé primaire doit être considérée comme « une donnée système » indépendante des données elles-même et qui ne servent qu'au SGBD, mais ne doivent pas être utilisées par l'utilisateur final de l'application au même titre que les données qu'il a normalement à manipuler.
Exemple : dans une table où j'aurais les colonnes nom, prenom et email, il pourrait être tentant d'utiliser la colonne email comme clé primaire puisqu'on sait que ce sera toujours une donnée unique : ce serait une erreur de conception et il sera de loin préféérable d'avoir une colonne user_id en auto_increment : si l'utilisateur change de fournisseur et d'adresse de courriel, ça ne posera pas de problème de modifier cette information : mais si on s'en sert de clé primaire, ce sera une autre paire de manche de modifier cette donnée.
______________________________________________________________
Une question bien formulée, c'est un problème bien compris : ça représente déjà les 3/4 de la réponse ;)
Edited 1 time(s). Last edit at 03/04/2012 01:18PM by Jean Molliné.