Clause INNER JOIN ON sur la clause WHERE

Question

Par souci de simplicité, supposons que tous les champs pertinents sont NOT NULL.

Vous pouvez faire:

SELECT
    table1.this, table2.that, table2.somethingelse
FROM
    table1, table2
WHERE
    table1.foreignkey = table2.primarykey
    AND (some other conditions)

Ou bien:

SELECT
    table1.this, table2.that, table2.somethingelse
FROM
    table1 INNER JOIN table2
    ON table1.foreignkey = table2.primarykey
WHERE
    (some other conditions)

Ces deux éléments fonctionnent-ils de la même manière dans MySQL?

Answer 1

INNER JOIN est la syntaxe ANSI que vous devriez utiliser.

Il est généralement considéré comme plus lisible, en particulier lorsque vous joignez de nombreuses tables.

Il peut également être facilement remplacé par un OUTER JOIN chaque fois que le besoin s'en fait sentir.

La syntaxe WHERE est davantage axée sur les modèles relationnels.

Un résultat de deux tables JOIN ed est un produit cartésien des tables auxquelles est appliqué un filtre qui sélectionne uniquement les lignes dont les colonnes de jointure correspondent.

Il est plus facile de voir cela avec la STRAIGHT_JOIN syntaxe.

Comme pour votre exemple, dans MySQL (et dans SQL en général), ces deux requêtes sont synonymes.

Notez également que MySQL possède également une <=> clause.

A l'aide de cette clause, vous pouvez contrôler l'ordre <=>: quelle table est analysée dans la boucle externe et quelle est dans la boucle interne.

Vous ne pouvez pas contrôler cela dans MySQL avec <=> la syntaxe.

Answer 2

D'autres ont souligné qu'INNER JOIN améliore la lisibilité, ce qui est une priorité absolue. Je suis d'accord. Laissez-moi essayer d’expliquer pourquoi la syntaxe de la jointure est plus lisible.

Une requête SELECT de base est la suivante:

SELECT stuff
FROM tables
WHERE conditions

La clause SELECT nous indique ce que nous récupérons; la clause FROM nous indique d'où nous l'obtenons, et la clause WHERE nous indique lesquels nous obtenons.

JOIN est une déclaration sur les tables, sur la manière dont elles sont liées (conceptuellement, en fait, dans une seule table). Tous les éléments de requête qui contrôlent les tables - d'où nous obtenons des éléments - appartiennent sémantiquement à la clause FROM (et bien entendu, c'est là que vont les éléments JOIN). L'insertion d'éléments de jointure dans la clause WHERE associe les éléments which et where-from ; c'est pourquoi la syntaxe JOIN est préférée.

Answer 3

Application d'instructions conditionnelles dans ON / WHERE

J'ai expliqué les étapes de traitement d'une requête logique.

Référence: Inside Microsoft & # 174; SQL Server & # 8482; Interrogation T-SQL 2005
Editeur: Microsoft Press
Date de publication: 07 mars 2006
Imprimer ISBN-10: 0-7356-2313-9
Imprimer ISBN-13: 978-0-7356-2313-2
Pages: 640

Dans Microsoft N ° 174; SQL Server & # 8482; Interrogation T-SQL 2005

(8)  SELECT (9) DISTINCT (11) TOP <top_specification> <select_list>
(1)  FROM <left_table>
(3)       <join_type> JOIN <right_table>
(2)       ON <join_condition>
(4)  WHERE <where_condition>
(5)  GROUP BY <group_by_list>
(6)  WITH {CUBE | ROLLUP}
(7)  HAVING <having_condition>
(10) ORDER BY <order_by_list>

Le premier aspect notable de SQL différent des autres langages de programmation est l’ordre dans lequel le code est traité. Dans la plupart des langages de programmation, le code est traité dans l'ordre dans lequel il est écrit. En SQL, la première clause traitée est la clause FROM, tandis que la clause SELECT, qui apparaît en premier, est traitée presque en dernier.

Chaque étape génère une table virtuelle utilisée comme entrée pour l'étape suivante. Ces tables virtuelles ne sont pas disponibles pour l'appelant (application client ou requête externe). Seule la table générée par l'étape finale est renvoyée à l'appelant. Si une certaine clause n'est pas spécifiée dans une requête, l'étape correspondante est simplement ignorée.

Brève description des phases de traitement des requêtes logiques

Ne vous inquiétez pas trop si la description des étapes ne semble pas avoir beaucoup de sens pour le moment. Celles-ci sont fournies à titre de référence. Les sections qui suivent l’exemple du scénario couvriront les étapes de manière beaucoup plus détaillée.

1. FROM: un produit cartésien (jointure croisée) est exécuté entre les deux premières tables de la clause FROM et génère ainsi la table virtuelle VT1.

2. ON: le filtre ON est appliqué à VT1. Seules les lignes pour lesquelles <join_condition> est VRAI sont insérées dans VT2.

3. OUTER (rejoindre): si une OUTER JOIN est spécifiée (par opposition à CROSS JOIN ou à INNER JOIN), les lignes de la table préservée ou les tables pour lesquelles aucune correspondance n'a été trouvée sont ajoutées aux lignes de VT2 en tant que lignes extérieures, générant VT3. Si plus de deux tables apparaissent dans la clause FROM, les étapes 1 à 3 sont appliquées à plusieurs reprises entre le résultat de la dernière jointure et la table suivante de la clause FROM jusqu'à ce que toutes les tables soient traitées.

4. WHERE: le filtre WHERE est appliqué à VT3. Seules les lignes pour lesquelles <where_condition> est VRAI sont insérées dans VT4.

5. GROUP BY: Les lignes de VT4 sont organisées en groupes basés sur la liste de colonnes spécifiée dans la clause GROUP BY. VT5 est généré.

6. CUBE | ROLLUP: des supergroupes (groupes de groupes) sont ajoutés aux lignes de VT5, générant VT6.

7. HAVING: le filtre HAVING est appliqué à VT6. Seuls les groupes pour lesquels <having_condition> est VRAI sont insérés dans VT7.

8. SELECT: la liste SELECT est traitée et génère VT8.

9. DISTINCT: Les lignes en double sont supprimées de VT8. VT9 est généré.

10. ORDER BY: Les lignes de VT9 sont triées selon la liste de colonnes spécifiée dans la clause ORDER BY. Un curseur est généré (VC10).

11. TOP: Le nombre ou le pourcentage de lignes spécifié est sélectionné depuis le début de VC10. La table VT11 est générée et renvoyée à l'appelant.

---

     Par conséquent, (INNER JOIN) ON filtrera les données (le nombre de données de VT sera réduit ici même) avant d'appliquer la clause WHERE. Les conditions de jointure suivantes seront exécutées avec des données filtrées, ce qui améliore les performances. Après cela, seule la condition WHERE appliquera les conditions de filtre.

(L'application d'instructions conditionnelles dans ON / WHERE ne changera pas grand-chose dans quelques cas. Cela dépend du nombre de tables que vous avez jointes et du nombre de lignes disponibles dans chaque table de jointure.)

Answer 4

La syntaxe ANSI de jointure implicite est ancienne, moins évidente et n'est pas recommandée.

De plus, l'algèbre relationnelle permet l'interchangeabilité des prédicats dans les clauses WHERE et INNER JOIN. Ainsi, même les requêtes <=> avec des clauses <=> peuvent avoir les prédicats réarrangés par l'optimiseur.

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

Parfois, cela implique de rendre le <=> relativement & "incomplet &"; et mettre certains des critères dans <=> simplement pour que les listes de critères de filtrage soient plus faciles à gérer.

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.

Answer 5

Les jointures implicites (c'est ce que votre première requête est connue) deviennent beaucoup plus confuses, difficiles à lire et à maintenir une fois que vous avez besoin d'ajouter de nouvelles tables à votre requête. Imaginez que vous fassiez la même requête et le même type de jointure sur quatre ou cinq tables différentes ... c’est un cauchemar.

L'utilisation d'une jointure explicite (votre deuxième exemple) est beaucoup plus lisible et facile à gérer.

Answer 6

Je tiens également à souligner que l'utilisation de l'ancienne syntaxe est plus sujette aux erreurs. Si vous utilisez des jointures internes sans clause ON, vous obtiendrez une erreur de syntaxe. Si vous utilisez l'ancienne syntaxe et oubliez l'une des conditions de jointure de la clause where, vous obtiendrez une jointure croisée. Les développeurs résolvent souvent ce problème en ajoutant le mot clé distinct (plutôt que de fixer la jointure car ils ne réalisent toujours pas que la jointure est cassée), ce qui peut sembler résoudre le problème, mais ralentit considérablement la requête.

De plus, pour la maintenance, si l’ancienne syntaxe contient une jointure croisée, comment le responsable peut-il savoir si vous voulez en avoir une (il existe des situations dans lesquelles des jointures croisées sont nécessaires) ou s’il s’agit d’un accident qui doit être corrigé? / p>

Permettez-moi de vous indiquer cette question pour savoir pourquoi la syntaxe implicite est mauvaise si vous utilisez des jointures à gauche. Sybase * = à Ansi Standard avec 2 tables externes différentes pour la même table interne

De plus (discours personnel ici), la norme utilisant les jointures explicites a plus de 20 ans, ce qui signifie que la syntaxe de jointure implicite est obsolète depuis 20 ans. Voulez-vous écrire un code d'application en utilisant une syntaxe obsolète depuis 20 ans? Pourquoi voulez-vous écrire le code de base de données?

Answer 7

Ils ont un sens différent de celui qui est lisible par l'homme.

Toutefois, en fonction de l'optimiseur de requête, ils peuvent avoir la même signification pour la machine.

Vous devriez toujours coder pour être lisible.

En d’autres termes, s’il s’agit d’une relation intégrée, utilisez la jointure explicite. si vous comparez des données faiblement liées, utilisez la clause where.

Answer 8

La norme SQL: 2003 a modifié certaines règles de priorité afin qu'une instruction JOIN soit prioritaire sur une & virgule " joindre. Cela peut réellement changer les résultats de votre requête en fonction de la configuration. Cela pose des problèmes à certaines personnes lorsque MySQL 5.0.12 est passé au respect de la norme.

Ainsi, dans votre exemple, vos requêtes fonctionneraient de la même manière. Mais si vous avez ajouté une troisième table: SELECT ... FROM table1, table2 JOIN table3 sur ... où ...

Avant MySQL 5.0.12, table1 et table2 étaient d'abord liés, puis table3. Maintenant (5.0.12 et après), table2 et table3 sont d'abord joints, puis table1. Cela ne change pas toujours les résultats, mais cela est possible et vous pouvez même ne pas vous en rendre compte.

Je n’utilise jamais la " virgule " syntaxe plus, optant pour votre deuxième exemple. De toute façon, les conditions de JOIN sont bien plus lisibles, elles ne sont pas séparées dans une section de requête séparée.

Answer 9

Je sais que vous parlez de MySQL, mais enfin: Dans Oracle 9, les jointures explicites et implicites généreraient différents plans d'exécution. Une réponse à ma question qui a été résolue dans Oracle 10+: il n'y a plus de telle différence.

Answer 10

La syntaxe de jointure ANSI est nettement plus portable.

Je suis en train de passer à une version améliorée de Microsoft SQL Server. Je mentionnerais également que la syntaxe = * et * = des jointures externes dans SQL Server n'est pas prise en charge (sans mode de compatibilité) pour les serveurs SQL 2005 et ultérieurs.