Jointure interne vs où

Existe-t-il une différence de performances (dans Oracle) entre

Select * from Table1 T1 
Inner Join Table2 T2 On T1.ID = T2.ID

Et

Select * from Table1 T1, Table2 T2 
Where T1.ID = T2.ID

?

Non! Le même plan d'exécution, regardez ces deux tableaux:

CREATE TABLE table1 (
  id INT,
  name VARCHAR(20)
);

CREATE TABLE table2 (
  id INT,
  name VARCHAR(20)
);

Plan d'exécution de la requête à l'aide de la jointure interne:

-- with inner join

EXPLAIN PLAN FOR
SELECT * FROM table1 t1
INNER JOIN table2 t2 ON t1.id = t2.id;

SELECT *
FROM TABLE (DBMS_XPLAN.DISPLAY);

-- 0 select statement
-- 1 hash join (access("T1"."ID"="T2"."ID"))
-- 2 table access full table1
-- 3 table access full table2

Et le plan d'exécution de la requête à l'aide d'une clause WHERE.

-- with where clause

EXPLAIN PLAN FOR
SELECT * FROM table1 t1, table2 t2
WHERE t1.id = t2.id;

SELECT *
FROM TABLE (DBMS_XPLAN.DISPLAY);

-- 0 select statement
-- 1 hash join (access("T1"."ID"="T2"."ID"))
-- 2 table access full table1
-- 3 table access full table2

Si l'optimiseur de requêtes fait bien son travail, il ne devrait pas y avoir de différence entre ces requêtes. Ce ne sont que deux façons de spécifier le même résultat souhaité.

Ils devraient être exactement les mêmes. Cependant, en tant que pratique de codage, je préfère voir la jointure. Il exprime clairement votre intention,

En utilisant JOIN rend le code plus facile à lire, car il est explicite.

Il n'y a pas de différence de vitesse ( je viens de le tester ) et le plan d'exécution est le même.

Je ne connais pas Oracle mais je sais que l'ancienne syntaxe est déconseillée dans SQL Server et disparaîtra finalement. Avant d'utiliser cette ancienne syntaxe dans une nouvelle requête, je vérifiais ce que Oracle prévoyait d'en faire.

Je préfère la nouvelle syntaxe plutôt que le mélange des critères de jointure avec d'autres conditions nécessaires. Dans la nouvelle syntaxe, il est beaucoup plus clair ce qui crée la jointure et quelles autres conditions sont appliquées. Ce n'est pas vraiment un gros problème dans une courte requête comme celle-ci, mais cela devient beaucoup plus déroutant lorsque vous avez une requête plus complexe. Étant donné que les gens apprennent sur les requêtes de base, j'aurais tendance à préférer que les gens apprennent à utiliser la syntaxe de jointure avant d'en avoir besoin dans une requête complexe.

Et encore une fois, je ne connais pas spécifiquement Oracle, mais je sais que la version SQL Server de l'ancienne jointure gauche est défectueuse même dans SQL Server 2000 et donne des résultats incohérents (parfois une jointure gauche parfois une jointure croisée), donc elle ne devrait jamais être utilisé. Espérons que Oracle ne souffre pas du même problème, mais les jointures gauche et droite peuvent être plus difficiles à exprimer correctement dans l'ancienne syntaxe.

De plus, d'après mon expérience (et bien sûr, il s'agit strictement d'une opinion personnelle, vous pouvez avoir une expérience différente), les développeurs qui utilisent les jointures standard ANSII ont tendance à mieux comprendre ce qu'est une jointure et ce qu'elle signifie en termes d'obtention les données de la base de données. Je crois que c'est parce que la plupart des personnes ayant une bonne compréhension des bases de données ont tendance à écrire des requêtes plus complexes et celles-ci me semblent beaucoup plus faciles à maintenir en utilisant la norme ANSII que l'ancien.

[Pour un point bonus ...]

L'utilisation de la syntaxe JOIN vous permet de commenter plus facilement la jointure car elle est tout inclus sur une seule ligne. Cela peut être utile si vous déboguez une requête complexe

Comme tout le monde le dit, ils sont fonctionnellement les mêmes, mais le JOIN est plus clair d'une déclaration d'intention. Cela peut donc aider l'optimiseur de requêtes dans les versions actuelles d'Oracle dans certains cas (je n'en ai aucune idée), il peut aider l'optimiseur de requêtes dans les futures versions d'Oracle (personne n'en a la moindre idée), ou il peut être utile si vous changez de fournisseur de base de données.

Ils sont logiquement identiques, mais dans les versions antérieures d'Oracle qui adoptaient la syntaxe ANSI, il y avait souvent des bogues avec elle dans des cas plus complexes, vous rencontrerez donc parfois une résistance des développeurs Oracle lors de son utilisation.

Les performances devraient être identiques, mais je suggérerais d'utiliser la version join en raison d'une meilleure clarté en ce qui concerne les jointures externes.

Les produits cartésiens non intentionnels peuvent également être évités en utilisant la version join.

Un troisième effet est un SQL plus facile à lire avec une condition WHERE plus simple.

N'oubliez pas que dans Oracle, à condition que les attributs de clé de jointure soient nommés de la même manière dans les deux tables, vous pouvez également écrire ceci comme:

select *
from Table1 inner join Table2 using (ID);

Cela a également le même plan de requête, bien sûr.

Dans un scénario où les tables sont en 3e forme normale, les jointures entre les tables ne doivent pas changer. C'est à dire rejoindre les CLIENTS et les PAIEMENTS doivent toujours rester les mêmes.

Cependant, nous devons distinguer les jointures des filtres . Les jointures concernent les relations et les filtres concernent le partitionnement d'un ensemble.

Certains auteurs, se référant à la norme (c.-à-d. Jim Melton; Alan R. Simon (1993). Understanding The New SQL: A Complete Guide. Morgan Kaufmann. Pp. 11–12. ISBN 978-1-55860-245-8.) , a écrit sur les avantages d'adopter la syntaxe JOIN sur les tables séparées par des virgules dans la clause FROM.

Je suis totalement d'accord avec ce point de vue.

Il existe plusieurs façons d'écrire SQL et d'obtenir les mêmes résultats, mais pour beaucoup de ceux qui travaillent en équipe, la lisibilité du code source est un aspect important, et séparer certainement la façon dont les tables se relient les unes aux autres à partir de filtres spécifiques a été un grand pas en avant dans la clarification de la source code.

Dans PostgreSQL, il n'y a certainement aucune différence - ils correspondent tous deux au même plan de requête. Je suis sûr à 99% que c'est également le cas pour Oracle.

Ce sont deux jointures internes qui font la même chose, on utilise simplement la nouvelle syntaxe ANSI.

Fonctionnellement, ils sont identiques à ce qui a été dit. Je suis d'accord cependant que faire la jointure est préférable pour décrire exactement ce que vous voulez faire. Beaucoup de fois, j'ai pensé que je savais comment je voulais interroger quelque chose jusqu'à ce que je commence à faire les jointures et j'ai réalisé que je voulais faire une requête différente de celle d'origine dans ma tête.

Il est vrai que, fonctionnellement, les deux requêtes doivent être traitées de la même manière. Cependant, l'expérience a montré que si vous sélectionnez à partir de vues qui utilisent la nouvelle syntaxe de jointure, il est important de structurer vos requêtes en l'utilisant également. L'optimiseur d'Oracle peut être confus si une vue utilise une instruction "join", mais une requête accédant à la vue utilise la méthode traditionnelle de jointure dans la clause "where".

Bien que l'identité de deux requêtes semble évidente, parfois des choses étranges se produisent. Je suis tombé sur la requête qui a différents plans d'exécution lors du déplacement du prédicat de jointure de JOIN vers WHERE dans Oracle 10g (pour le plan WHERE, c'est mieux), mais je ne peux pas reproduire ce problème dans des tableaux et des données simplifiés. Je pense que cela dépend de mes données et statistiques. L'optimiseur est un module assez complexe et il se comporte parfois comme par magie.

C'est pourquoi nous ne pouvons pas répondre à cette question en général car cela dépend des internes DB. Mais nous devons savoir que la réponse doit être « aucune différence ».

j'ai eu cette énigme aujourd'hui lors de l'inspection de l'un des délais de production de notre sp, changé une jointure interne sur une table construite à partir d'un flux xml en une clause `` où '' à la place .... le temps d'exécution moyen est maintenant de 80 ms sur 1000 exécutions, tandis que avant que le taux d'exécution moyen ne soit de 2,2 secondes ... la principale différence dans le plan d'exécution est la disparition d'une recherche de clé ... Le message étant que vous ne saurez pas jusqu'à ce que vous ayez testé en utilisant les deux méthodes.

à votre santé.

Ils sont tous les deux joints et où cela fait la même chose.

Jetez un œil aux requêtes In MySQL, pourquoi utiliser join au lieu de où?

Comme l'a dit Kiewik, le plan d'exécution est le même.

L'instruction JOIN est seulement plus facile à lire, ce qui permet de ne pas oublier la condition ON et d'obtenir un produit cartésien. Ces erreurs peuvent être assez difficiles à détecter dans les longues requêtes utilisant plusieurs jointures de type: SELECT * FROM t1, t2 WHERE t1.id = t2.some_field.

Si vous oubliez une seule condition de jointure, vous obtenez une requête d'exécution très longue renvoyant trop d'enregistrements ... vraiment trop. Certains poeple utilisent un DISTINCT pour patcher la requête, mais son exécution est encore très longue.

C'est précisément pourquoi, l'utilisation de l'instruction JOIN est certainement la meilleure pratique: une meilleure maintenabilité et une meilleure lisibilité.

De plus, si je me souviens bien, JOIN est optimisé en ce qui concerne l'utilisation de la mémoire.

J'ai un ajout à cette bonne réponse :

C'est ce qui est défini comme SQL92 et SQL89 respectivement, il n'y a pas de différence de performances entre eux bien que vous puissiez omettre le mot INNER (en utilisant simplement JOIN est assez clair et dans la requête la plus simple vous enregistrez 5 coups de clavier, imaginez maintenant combien de coups il y a en gros les uns).