IP Girl
  1. IP Girl
  3. L’ordre de jointure est-il important en SQL?
Intereting Posts
Existe-t-il une classe de paire clé / valeur générique sérialisable dans .NET? Comment créer un lien vers un fichier local sur une page Web exécutée localement? Dans Kotlin, quelle est la manière idiomatique de traiter les valeurs nulles, de les référencer ou de les convertir? Quelle est la différence entre Observable, Completable et Single dans RxJava Comment atsortingbuer un alias à un nom de fonction en C ++? Masquer les éléments dans les menus contextuels du clic droit dans Visual Studio 2010 (08)? Comment puis-je désactiver ReSharper dans Visual Studio et l’activer à nouveau? Expression angular si le tableau contient un très long ssortingng Le type de valeur par défaut ne correspond pas au type de la propriété Comment supprimer des aberrations d’un dataset Sublime Text 2 – Afficher la navigation dans la barre latérale Pour exécuter dex en cours, le démon Gradle a besoin d’un segment de mémoire plus important. Il a actuellement environ 910 Mo Erreur de clé de registre: la version Java a la valeur ‘1.8’, mais ‘1.7’ est requirejs Comment puis-je déployer (créer .ipa) une application iphone en utilisant ‘cordova build ios –release’?

L’ordre de jointure est-il important en SQL?

Sans tenir compte des performances, vais-je obtenir le même résultat de la requête A et B ci-dessous? Qu’en est-il de C et D? 

-- A select * from a left join b on  left join c on  -- B select * from a left join c on  left join b on  -- C select * from a join b on  join c on  -- D select * from a join c on  join b on

Pour INNER joint, non, l’ordre ne compte pas. Les requêtes renverront les mêmes résultats, tant que vous sélectionnerez SELECT * à SELECT a.*, b.*, c.* .

Pour ( LEFT , RIGHT ou FULL ) les jointures OUTER , oui, l’ordre compte – et ( mis à jour ) les choses sont beaucoup plus compliquées.

Tout d’abord, les jointures externes ne sont pas commutatives, donc a LEFT JOIN b n’est pas la même que b LEFT JOIN a

Les jointures externes ne sont pas non plus associatives, donc dans vos exemples impliquant des propriétés à la fois (commutativité et associativité): 

 a LEFT JOIN b ON b.ab_id = a.ab_id LEFT JOIN c ON c.ac_id = a.ac_id

est équivalent à : 

 a LEFT JOIN c ON c.ac_id = a.ac_id LEFT JOIN b ON b.ab_id = a.ab_id

mais: 

 a LEFT JOIN b ON b.ab_id = a.ab_id LEFT JOIN c ON c.ac_id = a.ac_id AND c.bc_id = b.bc_id

n’est pas équivalent à : 

 a LEFT JOIN c ON c.ac_id = a.ac_id LEFT JOIN b ON b.ab_id = a.ab_id AND b.bc_id = c.bc_id

Un autre exemple d’associativité (plus simple). Pensez à ceci comme (a LEFT JOIN b) LEFT JOIN c : 

 a LEFT JOIN b ON b.ab_id = a.ab_id -- AB condition LEFT JOIN c ON c.bc_id = b.bc_id -- BC condition

Ceci équivaut à a LEFT JOIN (b LEFT JOIN c) : 

 a LEFT JOIN b LEFT JOIN c ON c.bc_id = b.bc_id -- BC condition ON b.ab_id = a.ab_id -- AB condition

seulement parce que nous avons de “bonnes” conditions ON . ON b.ab_id = a.ab_id et c.bc_id = b.bc_id sont des vérifications d’égalité et n’impliquent pas de comparaisons NULL .

Vous pouvez même avoir des conditions avec d’autres opérateurs ou plus complexes comme: ON ax <= bx ou ON ax = 7 ou ON ax LIKE bx ou ON (ax, ay) = (bx, by) et les deux requêtes seraient toujours équivalentes .

Si toutefois, l'une de ces fonctions IS NULL ou une fonction liée à des COALESCE() nulles comme COALESCE() , par exemple si la condition était b.ab_id IS NULL , les deux requêtes ne seraient pas équivalentes.

pour les jointures régulières, ce n’est pas le cas. TableA join TableB produira le même plan d’exécution que la TableB join TableA (vos exemples C et D seraient donc les mêmes)

pour la gauche et la droite se joint à elle. TableA left Join TableB est différent de TableB left Join TableA , mais c’est la même chose que TableB right Join TableA

Si vous essayez de joindre C sur un champ de B avant de rejoindre B, c’est-à-dire: 

 SELECT Ax, Ay, Az FROM A INNER JOIN C on Bx = Cx INNER JOIN b on Ax = Bx

Votre requête échouera, et dans ce cas, la commande est importante.