1072 votes

JOINTURE INTERNE SUR vs clause where

Pour des raisons de simplicité, supposons que tous les champs ne sont PAS NULL.

Vous pouvez le faire:

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

Ou encore:

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

Les deux ont travaillé sur le même chemin, par MySQL?

770voto

Quassnoi Points 191041

INNER JOIN est ANSI de la syntaxe que vous devriez utiliser.

Il est généralement considéré comme plus lisible, surtout quand vous vous joignez à beaucoup de tables.

Il peut aussi être facilement remplacés par un OUTER JOIN chaque fois qu'un besoin se fait sentir.

L' WHERE syntaxe est plus le modèle relationnel orienté.

À la suite de deux tables JOIN'ed est un produit cartésien des tables pour lesquelles un filtre est appliqué, ce qui sélectionne uniquement les lignes avec les colonnes de jointure de correspondance.

Il est plus facile de voir cela avec l' WHERE de la syntaxe.

Quant à votre exemple, en MySQL (et en SQL généralement) ces deux requêtes sont synonymes.

Notez aussi que l' MySQL a également un STRAIGHT_JOIN de la clause.

L'utilisation de cette clause, vous pouvez contrôler l' JOIN ordre: la table qui est analysé dans la boucle externe et que l'on est dans la boucle interne.

Vous ne pouvez pas contrôler ce en MySQL l'aide WHERE de la syntaxe.

221voto

Carl Manaster Points 23696

D'autres ont souligné que la JOINTURE INTERNE contribue à la lisibilité de l'homme, et c'est une priorité absolue; je suis d'accord. Laissez-moi vous expliquer pourquoi la syntaxe de jointure est plus lisible.

Une sélection de base de la requête est ceci:

SELECT stuff
FROM tables
WHERE conditions

La clause SELECT nous dit ce que nous sommes en train de dos; la clause from nous dit nous sommes en train de partir, et la clause where nous dit qui nous sommes arriver.

JOINDRE une déclaration sur les tables, la façon dont ils sont liés entre eux (sur le plan conceptuel, en fait, dans une seule table). Toute requête éléments qui permettent de contrôler les tables où nous sommes de plus en plus de choses à partir d' - sémantiquement appartiennent à la clause from (et bien sûr, c'est là que JOINDRE des éléments go). Mettre de rejoindre éléments dans la clause where regroupe le qui et le où-à partir; c'est pourquoi la syntaxe de JOINTURE est préféré.

156voto

rafidheen Points 341

L'application des instructions conditionnelles dans / OÙ

Ici, j'ai expliqué au sujet de la requête logique des étapes de traitement.


Référence : à l'Intérieur de Microsoft® SQL Server™ 2005 T-SQL d'Interrogation
Editeur: Microsoft Press
Pub Date: 07 Mars 2006
Imprimer ISBN-10: 0-7356-2313-9
Imprimer ISBN-13: 978-0-7356-2313-2
Pages: 640

À l'intérieur de Microsoft® SQL Server™ 2005 T-SQL d'Interrogation

(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 qui est 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é dans la clause from, tandis que la clause SELECT, qui apparaît d'abord, est traité 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 à l'appelant (le client demande ou de la requête externe). Seul le tableau généré par la dernière étape est retourné à l'appelant. Si une clause n'est pas spécifié dans une requête, l'étape correspondante est simplement ignorée.

Brève Description de la Logique de Traitement de Requête Phases Ne vous inquiétez pas trop si la description des étapes ne semble pas faire beaucoup de sens pour l'instant. Ces sont fournies à titre de référence. Les Sections qui viennent après le scénario d'exemple, permettra de couvrir les étapes plus en détail.

  1. DE: UN produit Cartésien (cross join) est réalisée entre les deux premières tables dans la clause from, et comme un résultat, table virtuelle VT1 est généré.

  2. SUR: Le filtre est appliqué à VT1. Seules les lignes pour lesquelles la est VRAI, sont insérés pour VT2.

  3. EXTÉRIEURS (à joindre): Si une JOINTURE EXTERNE est indiqué (par opposition à une JOINTURE CROISÉE ou une JOINTURE INTERNE), les lignes de la préservés de la table ou les tables pour lesquelles un match n'a pas été trouvé, sont ajoutés les lignes de VT2 que les rangées extérieures, générant VT3. Si plus de deux tables apparaissent dans la clause from, les étapes 1 à 3 sont applicables à plusieurs reprises entre le résultat de la jointure dernière et de la prochaine table dans la clause from jusqu'à ce que toutes les tables sont traitées.

  4. OÙ: La OÙ le filtre est appliqué à VT3. Seules les lignes pour lesquelles la est VRAI, sont insérés sur VT4.

  5. GROUPE PAR: Les lignes de VT4 sont disposées par groupes en fonction de la liste des colonnes spécifiées dans la clause GROUP BY. VT5 est généré.

  6. CUBE | CUMULATIF: super-groupes (groupes de groupes) sont ajoutés les lignes de VT5, générant VT6.

  7. DEVOIR: Le DEVOIR filtre est appliqué à VT6. Seuls les groupes pour qui la est VRAI, sont insérés pour VT7.

  8. SÉLECTIONNEZ: La liste de sélection est traitée, générant VT8.

  9. DISTINCTES: les Doublons sont supprimés à partir de VT8. VT9 est généré.

  10. COMMANDE PAR: Les lignes de VT9 sont triés en fonction de la liste des colonnes spécifiées dans la clause ORDER BY. Un curseur est généré (VC10).

  11. En HAUT: Le nombre ou le pourcentage spécifié de lignes est sélectionné à partir du début de VC10. Tableau VT11 est généré et est retourné à l'appelant.



Par conséquent, (INNER JOIN) SUR filtre les données (les données de comptage de VT sera réduit ici même) avant d'appliquer la clause where. Les ultérieur des conditions de jointure sera exécuté avec les données filtrées qui permet de meilleures performances. Après cela seulement si la condition s'appliquera conditions de filtre.

(Application des instructions conditionnelles dans / OÙ ne fera pas beaucoup de différence dans quelques cas. Cela dépend du nombre de tables que vous avez rejoint et le nombre de lignes disponibles dans chacune des tables de jointure)

71voto

Cade Roux Points 53870

La jointure implicite syntaxe ANSI est plus âgé, moins évidente et n'est pas recommandé.

En outre, l'algèbre relationnelle permet l'interchangeabilité des prédicats dans l' WHERE de la clause et l' INNER JOIN, de sorte que même INNER JOIN des requêtes avec des WHERE clauses peuvent avoir les prédicats rearrranged par l'optimiseur.

Je vous recommande d'écrire les requêtes dans la plupart des readble façon possible.

Parfois, cela inclut la mise à l' INNER JOIN relativement "incomplet" et de mettre certains critères de la WHERE tout simplement pour faire les listes de critères de filtrage plus facilement maintenable.

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.

37voto

matt b Points 73770

Implicite des jointures (qui est ce que votre première requête est connu comme) deviennent beaucoup beaucoup plus confus, difficile à lire, et difficiles à maintenir une fois que vous avez besoin pour commencer à ajouter plus de tables à votre requête. Imaginer faire la même requête et le type de jointure sur quatre ou cinq tables différentes ... c'est un cauchemar.

À l'aide d'un explicite join (votre deuxième exemple) est beaucoup plus lisible et facile à entretenir.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X