Condition dans JOIN ou WHERE

Y a-t-il une différence (performances, bonnes pratiques, etc.) entre la mise d'une condition dans la clause JOIN et la clause WHERE?

Par exemple...

-- Condition in JOIN
SELECT *
FROM dbo.Customers AS CUS
INNER JOIN dbo.Orders AS ORD 
ON CUS.CustomerID = ORD.CustomerID
AND CUS.FirstName = 'John'

-- Condition in WHERE
SELECT *
FROM dbo.Customers AS CUS
INNER JOIN dbo.Orders AS ORD 
ON CUS.CustomerID = ORD.CustomerID
WHERE CUS.FirstName = 'John'

Lequel préférez-vous (et peut-être pourquoi)?

L'algèbre relationnelle permet l'interchangeabilité des prédicats dans la WHEREclause et le INNER JOIN, de sorte que même les INNER JOINrequêtes avec des WHEREclauses peuvent avoir les prédicats réorganisés par l'optimiseur afin qu'ils puissent déjà être exclus pendant le JOINprocessus.

Je vous recommande d'écrire les requêtes de la manière la plus lisible possible.

Parfois, cela implique de rendre les INNER JOINcritères relativement "incomplets" et d'insérer certains des critères WHEREsimplement pour rendre les listes de critères de filtrage plus faciles à maintenir.

Par exemple, au lieu de:

SELECT *
FROM Customers c
INNER JOIN CustomerAccounts ca
    ON ca.CustomerID = c.CustomerID
    AND c.State = 'NY'
INNER JOIN Accounts a
    ON ca.AccountID = a.AccountID
    AND a.Status = 1

Écrire:

SELECT *
FROM Customers c
INNER JOIN CustomerAccounts ca
    ON ca.CustomerID = c.CustomerID
INNER JOIN Accounts a
    ON ca.AccountID = a.AccountID
WHERE c.State = 'NY'
    AND a.Status = 1

Mais cela dépend, bien sûr.

Pour les jointures internes, je n'ai pas vraiment remarqué de différence (mais comme pour tous les réglages de performances, vous devez vérifier votre base de données dans vos conditions).

Cependant, l'emplacement de la condition fait une énorme différence si vous utilisez des jointures gauche ou droite. Par exemple, considérez ces deux requêtes:

SELECT *
FROM dbo.Customers AS CUS 
LEFT JOIN dbo.Orders AS ORD 
ON CUS.CustomerID = ORD.CustomerID
WHERE ORD.OrderDate >'20090515'

SELECT *
FROM dbo.Customers AS CUS 
LEFT JOIN dbo.Orders AS ORD 
ON CUS.CustomerID = ORD.CustomerID
AND ORD.OrderDate >'20090515'

Le premier ne vous donnera que les enregistrements dont l'ordre est postérieur au 15 mai 2009, convertissant ainsi la jointure gauche en jointure interne.

Le second donnera ces enregistrements ainsi que tous les clients sans commande. L'ensemble de résultats est très différent selon l'endroit où vous placez la condition. (Sélectionnez * à titre d'exemple uniquement, bien sûr, vous ne devez pas l'utiliser dans le code de production.)

L'exception à cela est lorsque vous souhaitez afficher uniquement les enregistrements dans une table mais pas dans l'autre. Ensuite, vous utilisez la clause where pour la condition et non la jointure.

SELECT *
FROM dbo.Customers AS CUS 
LEFT JOIN dbo.Orders AS ORD 
ON CUS.CustomerID = ORD.CustomerID
WHERE ORD.OrderID is null

La plupart des produits SGBDR optimiseront les deux requêtes de manière identique. Dans «SQL Performance Tuning» de Peter Gulutzan et Trudy Pelzer, ils ont testé plusieurs marques de SGBDR et n'ont trouvé aucune différence de performances.

Je préfère garder les conditions de jointure séparées des conditions de restriction de requête.

Si vous utilisez OUTER JOINparfois, il est nécessaire de mettre des conditions dans la clause de jointure.

WHERE filtrera après la jointure.

Filtrez sur JOIN pour empêcher l'ajout de lignes pendant le processus JOIN.

Je préfère le JOIN pour joindre des tables / vues complètes, puis utiliser le WHERE pour introduire le prédicat de l'ensemble résultant.

Il semble syntaxiquement plus propre.

Je constate généralement une augmentation des performances lors du filtrage sur la jointure. Surtout si vous pouvez joindre des colonnes indexées pour les deux tables. Vous devriez être en mesure de réduire les lectures logiques avec la plupart des requêtes qui le font également, ce qui, dans un environnement à volume élevé, est un bien meilleur indicateur de performances que le temps d'exécution.

Je suis toujours légèrement amusé quand quelqu'un montre son benchmarking SQL et qu'il a exécuté les deux versions d'un sproc 50 000 fois à minuit sur le serveur de développement et compare les temps moyens.

Mettre la condition dans la jointure me semble «sémantiquement faux», car ce n'est pas pour cela que les JOINs sont «pour». Mais c'est très qualitatif.

Problème supplémentaire: si vous décidez de passer d'une jointure interne à, par exemple, une jointure droite, le fait que la condition se trouve à l'intérieur de la jointure peut entraîner des résultats inattendus.

Les jointures sont à mon avis plus rapides lorsque vous avez une table plus grande. Ce n'est vraiment pas une grande différence, surtout si vous avez affaire à une table un peu plus petite. Quand j'ai découvert les jointures pour la première fois, on m'a dit que les conditions dans les jointures étaient exactement comme les conditions de la clause where et que je pourrais les utiliser de manière interchangeable si la clause where était spécifique à la table sur laquelle appliquer la condition.

Il est préférable d'ajouter la condition dans la jointure. Les performances sont plus importantes que la lisibilité. Pour les grands ensembles de données, c'est important.