SQL JOIN: ON vs Equals

Question

Y at-il de différence significative entre ce qui suit?

SELECT a.name, b.name FROM a, b WHERE a.id = b.id AND a.id = 1

SELECT a.name, b.name FROM a INNER JOIN b ON a.id = b.id WHERE a.id = 1

Avez-SO les utilisateurs ont une préférence de l'un sur l'autre?

Answer 1

Il n'y a pas de différence, mais la lisibilité du second est beaucoup mieux quand vous avez une grande requête multi-se joindre à des clauses supplémentaires où pour le filtrage.
La séparation des clauses de jointure et les clauses de filtre est une bonne chose:)

Answer 2

Le premier est la syntaxe ANSI 89, ce dernier est ANSI 92.

Pour cette requête spécifique il n'y a pas de différence. Cependant, avec l'ancien vous perdez la possibilité de séparer un filtre d'une condition de jointure dans les requêtes complexes, et la syntaxe pour spécifier GAUCHE vs vs droite INNER est souvent source de confusion, surtout si vous devez aller et venir entre les différents fournisseurs db. Je n'aime pas la syntaxe plus du tout.

Answer 3

Il n'y a pas de différence au moteur de requête SQL.

Pour faciliter la lecture, celle-ci est beaucoup plus facile à lire si vous utilisez et linebreaks indentation.

INNER JOIN, peu importe si vous mettez « filtres » et « joint » à ON ou clause WHERE, l'optimiseur de requête doit décider quoi faire en premier quand même (il peut choisir de faire un premier filtre, une jointure plus tard ou vice versa

Pour JOIN cependant OUTER, il y a une différence, et que vous voulez parfois vous aurez à mettre la condition dans la clause ON, parfois dans le WHERE. Mettre une condition dans la clause WHERE pour un OUTER JOIN peut se transformer en un INNER JOIN (à cause de la façon dont fonctionnent les valeurs NULL)

Par exemple, vérifier la lisibilité entre les deux exemples suivants:

SELECT c.customer_no, o.order_no, a.article_no, r.price
FROM customer c, order o, orderrow r, article a
WHERE o.customer_id = c.customer_id
AND r.order_id = o.order_id
AND a.article_id = r.article_id
AND o.orderdate >= '2003-01-01'
AND o.orderdate < '2004-01-01'
AND c.customer_name LIKE 'A%'
ORDER BY r.price DESC 

vs

SELECT c.customer_no, o.order_no, a.article_no, r.price
FROM customer c 
INNER JOIN order o
   ON  o.customer_id = c.customer_id
   AND o.orderdate >= '2003-01-01'
   AND o.orderdate < '2004-01-01'
INNER JOIN orderrow r
   ON  r.order_id = o.order_id
INNER JOIN article a 
   ON  a.article_id = r.article_id
WHERE  c.customer_name LIKE 'A%'
ORDER BY r.price DESC 

Answer 4

Alors que vous pouvez effectuer la plupart des tâches à l'aide à la fois et dans votre cas, il n'y a pas de différence que ce soit, je vais toujours utiliser la seconde en tout temps.

1. Il est la norme actuellement prise en charge
2. Il maintient des jointures dans la clause FROM et des filtres dans la clause WHERE
3. Il est plus complexe GAUCHE, DROITE, FULL OUTER joint beaucoup plus facile
4. MSSQL Aide est tout basée autour de cette syntaxe donc beaucoup plus facile d'obtenir de l'aide sur vos requêtes problème

Answer 5

Bien qu'il n'y ait pas de différence sur le plan technique, vous devez être très prudent de faire les jointures avec la première méthode. Si vous vous trompez par accident, vous pourriez finir par faire une jointure cartésienne entre votre a et tables b (une très longue mémoire et cpu requête intensive - il correspondra à chaque ligne unique dans toutes les lignes b Bad si. et b sont grandes tables pour commencer). L'utilisation d'un INNER JOIN explicites est à la fois plus sûr et plus facile à lire.

Answer 6

Pas de différence. Je trouve le premier format plus lisible et utiliser le second format que lorsque vous effectuez d'autres types de jointures (OUTER, GAUCHE INNER, etc).

Answer 7

La seconde forme est SQL92 syntaxe conforme. Cela devrait signifier qu'il est pris en charge par tous les fournisseurs de bases de données actuelles et futures. Cependant, la vérité est que la première forme est tellement répandu qu'il est également garanti d'être là pour plus longtemps que nous nous soucions.

Sinon, ils sont les mêmes à tous égards dans la façon dont les bases de données traitent les deux.