Pour simplifier, supposez que tous les champs pertinents le sont NOT NULL.

Tu peux faire:

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

Ou sinon:

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

Ces deux fonctionnent-ils de la même manière MySQL?

INNER JOIN est la syntaxe ANSI que vous devez utiliser.

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

Il peut également être facilement remplacé par un dès OUTER JOINque le besoin s'en fait sentir.

La WHEREsyntaxe est davantage orientée modèle relationnel.

Le résultat de deux tables JOINed est un produit cartésien des tables auxquelles un filtre est appliqué qui ne sélectionne que les lignes avec des colonnes de jointure correspondantes.

Il est plus facile de voir cela avec la WHEREsyntaxe.

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

Notez également que MySQL a également une STRAIGHT_JOINclause.

En utilisant cette clause, vous pouvez contrôler l' JOINordre: quelle table est analysée dans la boucle externe et laquelle se trouve dans la boucle interne.

Vous ne pouvez pas contrôler cela dans MySQL en utilisant la WHEREsyntaxe.

D'autres ont souligné que cela INNER JOINaide la lisibilité humaine, et c'est une priorité absolue, je suis d'accord.
Permettez-moi d'essayer d'expliquer pourquoi la syntaxe de jointure est plus lisible.

Une SELECTrequête de base est la suivante:

SELECT stuff
FROM tables
WHERE conditions

La SELECTclause nous dit ce que nous recevons; la FROMclause nous dit d' où nous la recevons, et la WHEREclause nous dit lesquelles nous obtenons.

JOIN est une déclaration sur les tables, comment elles sont liées ensemble (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 FROMclause (et bien sûr, c'est là que les JOINéléments vont). Mettre des éléments de jonction dans la WHEREclause confond le qui et le d' où , c'est pourquoi la JOINsyntaxe est préférée.

Appliquer des instructions conditionnelles dans ON / WHERE

Ici, j'ai expliqué les étapes de traitement des requêtes logiques.

Référence: Inside Microsoft® SQL Server ™ 2005 T-SQL Querying
Publisher: Microsoft Press
Pub Date: 07 mars 2006
Print ISBN-10: 0-7356-2313-9
Print ISBN-13: 978-0-7356-2313-2
Pages: 640

À l'intérieur de Microsoft® SQL Server ™ 2005 Requête T-SQL

(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 qui est 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 qui est 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 l'instant. Ils sont fournis à titre de référence. Les sections qui suivent l'exemple de scénario couvriront les étapes de manière beaucoup plus détaillée.

1. FROM: un produit cartésien (jointure croisée) est effectué entre les deux premières tables de la clause FROM et, par conséquent, la table virtuelle VT1 est générée.

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

3. OUTER (jointure): si une OUTER JOIN est spécifiée (par opposition à une CROSS JOIN ou une INNER JOIN), les lignes de la ou des tables préservées pour lesquelles aucune correspondance n'a été trouvée sont ajoutées aux lignes de VT2 en tant que lignes externes, 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 le <where_condition>est VRAI sont insérées dans VT4.

5. GROUP BY: Les lignes de VT4 sont organisées en groupes en fonction de 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 dont le <having_condition>est VRAI sont insérés dans VT7.

8. SELECT: La liste SELECT est traitée, générant 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 pourcentage spécifié de lignes est sélectionné depuis le début de VC10. La table VT11 est générée et renvoyée à l'appelant.

(L'application d'instructions conditionnelles dans ON / WHERE ne fera pas beaucoup de différence 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)

La syntaxe implicite de jointure ANSI est plus ancienne, moins évidente et déconseillée.

De plus, l'algèbre relationnelle permet l'interchangeabilité des prédicats dans la WHEREclause et la INNER JOIN, donc même les INNER JOINrequêtes avecWHERE 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 INNER JOINrelativement "incomplet" et de mettre certains des critèresWHERE simple 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.

Les jointures implicites (ce que l'on appelle votre première requête) deviennent beaucoup plus confuses, difficiles à lire et difficiles à maintenir une fois que vous devez commencer à ajouter plus de tables à votre requête. Imaginez faire 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 à entretenir.

Je soulignerai également que l'utilisation de l'ancienne syntaxe est plus sujette à erreur. 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 dans la clause where, vous obtiendrez une jointure croisée. Les développeurs corrigent souvent cela en ajoutant le mot-clé distinct (plutôt que de réparer la jointure car ils ne réalisent toujours pas que la jointure elle-même est rompue), ce qui peut sembler résoudre le problème, mais ralentira considérablement la requête.

De plus, pour la maintenance, si vous avez une jointure croisée dans l'ancienne syntaxe, comment le responsable saura-t-il si vous vouliez en avoir une (il y a des situations où des jointures croisées sont nécessaires) ou si c'est un accident qui devrait être corrigé?

Permettez-moi de vous indiquer cette question pour voir pourquoi la syntaxe implicite est mauvaise si vous utilisez des jointures gauches. Sybase * = selon Ansi Standard avec 2 tables extérieures différentes pour la même table intérieure

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

Ils ont une signification différente, lisible par l'homme.

Cependant, selon l'optimiseur de requêtes, ils peuvent avoir la même signification pour la machine.

Vous devez toujours coder pour être lisible.

Autrement dit, s'il s'agit d'une relation intégrée, utilisez la jointure explicite. si vous correspondez à des données faiblement liées, utilisez la clause where.

La norme SQL: 2003 a modifié certaines règles de priorité de sorte qu'une instruction JOIN a priorité sur une jointure «virgule». Cela peut en fait changer les résultats de votre requête en fonction de la façon dont elle est configurée. Cela peut causer 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 ON ... WHERE ...

Avant MySQL 5.0.12, table1 et table2 étaient jointes en premier, puis table3. Maintenant (5.0.12 et suivants), table2 et table3 sont jointes en premier, puis table1. Cela ne change pas toujours les résultats, mais cela peut et vous ne le réalisez peut-être même pas.

Je n'utilise plus la syntaxe "virgule", optant pour votre deuxième exemple. C'est beaucoup plus lisible de toute façon, les conditions JOIN sont avec les JOIN, pas séparées dans une section de requête séparée.

Je sais que vous parlez de MySQL, mais de toute façon: dans Oracle 9, les jointures explicites et implicites généreraient des plans d'exécution différents. AFAIK qui a été résolu dans Oracle 10+: il n'y a plus une telle différence.

La syntaxe de jointure ANSI est nettement plus portable.

Je passe par une mise à niveau de Microsoft SQL Server, et je mentionnerais également que la syntaxe = * et * = pour les jointures externes dans SQL Server n'est pas prise en charge (sans mode de compatibilité) pour 2005 sql server et versions ultérieures.

Si vous programmez souvent des procédures stockées dynamiques, vous tomberez amoureux de votre deuxième exemple (en utilisant où). Si vous avez différents paramètres d'entrée et beaucoup de dégâts de morphing, alors c'est la seule façon. Sinon, ils exécuteront tous les deux le même plan de requête, il n'y a donc aucune différence évidente dans les requêtes classiques.