MySQL Rejoindre Où N'existe Pas

Question

J'ai une requête MySQL qui joint deux tables

• Électeurs
• Ménages

Elles sont jointes sur voters.household_id et household.id.

Maintenant, ce que je dois faire, c'est la modifier pour que la table des électeurs soit jointe à une troisième table appelée elimination, le long de voter.id et elimination.voter_id. Cependant, la particularité est que je veux exclure tout enregistrement dans la table des électeurs qui a un enregistrement correspondant dans la table elimination.

Comment puis-je concevoir une requête pour cela ?

Voici ma requête actuelle :

SELECT `voter`.`ID`, `voter`.`Last_Name`, `voter`.`First_Name`,
       `voter`.`Middle_Name`, `voter`.`Age`, `voter`.`Sex`,
       `voter`.`Party`, `voter`.`Demo`, `voter`.`PV`,
       `household`.`Address`, `household`.`City`, `household`.`Zip`
FROM (`voter`)
JOIN `household` ON `voter`.`House_ID`=`household`.`id`
WHERE `CT` = '5'
AND `Precnum` = 'CTY3'
AND  `Last_Name`  LIKE '%Cumbee%'
AND  `First_Name`  LIKE '%John%'
ORDER BY `Last_Name` ASC
LIMIT 30

Answer 1

Faites attention aux JOINTURES "LEFT" - les JOINTURES LEFT sont essentiellement des JOINTURES OUTER. Les analyseurs de requêtes et les optimiseurs de requêtes des SGBDR différents peuvent gérer les JOINTURES OUTER de manière très différente. Prenons par exemple, comment les JOINTURES LEFT (OUTER) sont analysées par l'optimiseur de requêtes MySQL, et la différence dans les plans d'exécution résultants qu'ils pourraient évaluer par itération :

https://dev.mysql.com/doc/refman/8.0/en/outer-join-simplification.html

Les JOINTURES LEFT par leur nature même seront TOUJOURS Non Déterministes. À mon avis - elles ne devraient pas être utilisées dans le code de Production.

Je préfère rédiger les déclarations de type de JOINTURE d'une manière plus "vieille école" d'abord, en laissant de côté toute déclaration de JOINTURE spécifique. Laissez l'analyseur de requêtes du SGBDR faire ce pour quoi il est conçu - analyser votre déclaration et la traduire en plan d'exécution le plus optimal basé sur son évaluation de vos statistiques d'index et de votre conception de modèle de données. Cela dit, les analyseurs de requêtes / optimiseurs intégrés peuvent même se tromper, croyez-moi, je l'ai vu arriver de nombreuses fois. En général, je pense que prendre cette approche en premier fournit généralement des informations de base suffisantes pour prendre des décisions de réglage supplémentaires informées dans la plupart des cas.

Pour illustrer - en utilisant la requête de question de ce fil :

SELECT `voter`.`ID`, `voter`.`Last_Name`, `voter`.`First_Name`,
       `voter`.`Middle_Name`, `voter`.`Age`, `voter`.`Sex`,
       `voter`.`Party`, `voter`.`Demo`, `voter`.`PV`,
       `household`.`Address`, `household`.`City`, `household`.`Zip`
FROM (`voter`)
JOIN `household` ON `voter`.`House_ID`=`household`.`id`
WHERE `CT` = '5'
AND `Precnum` = 'CTY3'
AND  `Last_Name`  LIKE '%Cumbee%'
AND  `First_Name`  LIKE '%John%'

AND NOT EXISTS (
  SELECT * FROM `elimination`
   WHERE `elimination`.`voter_id` = `voter`.`ID`
)

ORDER BY `Last_Name` ASC
LIMIT 30

Considérez-le réécrit sans les déclarations JOIN explicites et NOT EXISTS ci-dessus (suppose que les champs non entièrement qualifiés dans la clause WHERE appartenaient à la table de votants) :

SELECT v.`ID`, v.`Last_Name`, v.`First_Name`,
       v.`Middle_Name`, v.`Age`, v.`Sex`,
       v.`Party`, v.`Demo`, v.`PV`,
       h.`Address`, h.`City`, h.`Zip`
FROM `voter` v, `household` h, `elimination` e
WHERE v.`House_ID` = h.`id`
AND v.`ID` != e.`voter_id`
AND v.`CT` = '5'
AND v.`Precnum` = 'CTY3'
AND  v.`Last_Name`  LIKE '%Cumbee%'
AND  v.`First_Name`  LIKE '%John%'
ORDER BY v.`Last_Name` ASC
LIMIT 30;

Essayez d'écrire certaines de vos futures requêtes SQL DES DEUX façons syntactiquement à l'avenir, comparez leurs résultats, et voyez ce que vous en pensez. Rédiger votre SQL dans le style que j'ai suggéré ci-dessus comporte l'avantage supplémentaire d'être plus agnostique vis-à-vis des SGBDR également.

Santé !