TABLE1 T1, TABLE2 T2 O T T1.Blah = T2.Blah - VS - INNER JOIN

Question

À condition que les tables puissent essentiellement être jointes, puisque la clause where exclut tous les enregistrements qui ne correspondent pas, exactement à quel point est-il mauvais d'utiliser la première des deux styles de syntaxe de l'instruction de requête suivante:

SELECT {COLUMN LIST} 
FROM TABLE1 t1, TABLE2 t2, TABLE3 t3, TABLE4 t4 (etc) 
WHERE t1.uid = t2.foreignid 
AND t2.uid = t3.foreignid 
AND t3.uid = t4.foreignid 
etc 

au lieu de

SELECT {COLUMN LIST} 
FROM TABLE1 t1 
INNER JOIN TABLE2 t2 ON t1.uid = t2.foreignid 
INNER JOIN TABLE3 t3 ON t2.uid = t3.foreignid 
INNER JOIN TABLE4 t4 ON t3.uid = t4.foreignid 

Je ne sais pas si cela est limité à Microsoft SQL, ou même une version particulière, mais mon la compréhension est que le premier scénario fait une jointure externe complète pour rendre toutes les corrélations possibles accessibles.

J'ai utilisé la première approche dans le passé pour optimiser les requêtes qui accèdent à deux grandes banques de données auxquelles sont associées des tables périphériques, le produit de ces jointures se rejoignant tard dans la requête. En permettant à chaque table "plus grande" de se joindre à ses tables de recherche respectives, et en combinant seulement un sous-ensemble spécifique de chacune des plus grandes tables, j'ai constaté qu'il y avait des améliorations de vitesse notables sur l'introduction des grandes tables avant le filtrage spécifique .

En situation normale (jointures simples), ne serait-il pas préférable d'utiliser le deuxième scénario? Je trouve que c'est plus facile à lire et il semble que ce sera beaucoup plus rapide.

Answer 1

INNER JOIN ON vs WHERE clause

Answer 2

Peut-être la meilleure façon de répondre à cette question est de jeter un oeil à la façon dont la base de données gère la requête interne. Si vous êtes sur SQL Server, utilisez Profiler pour voir combien de lectures etc. chaque requête prend et le plan de requête pour voir quelle route est prise à travers les données. Les statistiques, l'inclinaison, etc. joueront probablement aussi un rôle.

Answer 3

La première requête ne produit pas une jointure OUTER complète (qui est l'union des jointures GAUCHE et DROITE). Essentiellement à moins d'optimisations spécifiques à l'analyseur SQL [interne], les deux requêtes sont égales.

Answer 4

Personnellement, je n'utiliserais jamais la première syntaxe. Il peut en être de même en ce qui concerne les performances, mais il est plus difficile à entretenir et beaucoup plus sujet aux jointures accidentelles lorsque les choses deviennent complexes. Si vous ratez une condition ON, la vérification de la syntaxe échouera, si vous manquez l'une des conditions WHERE qui équivaut à une condition ON, elle fera heureusement une jointure croisée. C'est aussi une syntaxe qui a 17 ans de dépassement pour l'amour de Dieu! En outre, la syntaxe de jointure gauche et droite dans l'ancienne syntaxe est interrompue dans SQL Server et ne renvoie PAS toujours les résultats corrects (elle peut parfois interpeller les résultats en tant que jointure corss au lieu d'un joint externe) et ils ont été abandonnés et ne sera pas utilisable du tout dans la prochaine version. Si vous avez besoin de changer l'une des requêtes pour utiliser une jointure externe, alors vous pouvez essayer de réécrire en majuscules car il est particulièrement mauvais d'essayer de mélanger les deux types de syntaxe.