JOINTURE INTERNE SUR vs clause where

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

Que vous pouvez 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)

Ces deux fonctionnent sur le même chemin, en MySQL?

  • c'est ici
  • double possible de SQL left join vs plusieurs tables à PARTIR de la ligne?
  • Si j'ai bien compris, la première variante est la norme ANSI SQL-89 implicite de la syntaxe et de la deuxième variante est la norme ANSI SQL-92 explicite de la syntaxe de jointure. Les deux aboutissent au même résultat en se conformant SQL de mise en œuvre et à la fois résultat sera le même plan de requête dans bien fait implémentations de SQL. Personnellement, je préfère SQL-89 syntaxe mais beaucoup de gens préfèrent la syntaxe SQL-92.
  • Ce n'est pas un commentaire, il est une réponse. Cette question a 14 réponses, dont 3 avec plus de 50 points. Quel est votre commentaire à ajouter? Il me semble que c'est un troll sur SQL-89 vs SQL-92
  • J'étais en soulignant les noms officiels des syntaxes différentes. Aucune réponse dit explicitement le nom au complet, j'ai donc décidé d'ajouter ces commentaires. Cependant, mon commentaire n'a pas répondu à la question réelle, donc j'ai ajouté comme commentaire, non pas comme une réponse. (Haute voté réponses des allégations telles que "INNER JOIN est syntaxe ANSI" et "jointure implicite syntaxe ANSI est plus vieux" qui ne dit rien du tout parce que les deux syntaxes différentes ANSI syntaxes.)
InformationsquelleAutor JCCyC | 2009-06-19
  1. 658

    INNER JOIN est syntaxe ANSI 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.

    La WHERE syntaxe est plus le modèle relationnel orienté.

    À la suite de deux tables JOINed 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 le WHERE syntaxe.

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

    Également noter que MySQL a aussi un STRAIGHT_JOIN clause.

    L'utilisation de cette clause, vous pouvez contrôler la 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 dans MySQL à l'aide de WHERE syntaxe.

    • Merci, Quassnoi. Vous avez beaucoup de détails dans votre sna; est-il juste de dire que "oui, ces requêtes sont équivalentes, mais vous devez utiliser une jointure interne parce que c'est plus lisible, et plus facile à modifier"?
    • pour Oracle, SQL Server, MySQL et PostgreSQL — oui. Pour les autres systèmes, sans doute, aussi, mais il vaut mieux vérifier.
    • FWIW, à l'aide de virgules avec des conditions de jointure dans la WHERE clause est également conforme à la norme ANSI.
    • @Bill Karwin: JOIN mot-clé n'a pas été une partie de standards propriétaires jusqu'à ce que le passé plus récent qu'il peut sembler. Il a fait son chemin dans Oracle uniquement dans la version 9 et en PostgreSQL dans la version 7.2 (tous deux sortis en 2001). L'apparition de ce mot-clé a été une partie de ANSI adoption du standard, et c'est pourquoi ce mot-clé est généralement associée à ANSI, malgré le fait que ce dernier prend en charge la virgule comme un synonyme de CROSS JOIN ainsi.
    • Néanmoins, la norme ANSI SQL-89 spécifié rejoint à faire avec des virgules et des conditions dans un WHERE de l'alinéa (sans conditions, une jointure est équivalent à une jointure croisée, comme vous l'avez dit). ANSI SQL-92 a ajouté le JOIN de mots clés et connexes de la syntaxe, mais par des virgules de la syntaxe de style est toujours pris en charge pour la rétro-compatibilité.
    • InterBase 4.0 est un exemple d'un commercial SGBDR mise en œuvre qui ont soutenu JOIN syntaxe dès 1994.
    • Juste une remarque pour être clair, implicite vs explicite les jointures ne sont PAS les mêmes, implicite se joint à vous surprendra à chaque fois dans un certain temps quand "rien n'a changé", especifically lorsque vous traitez avec des valeurs nulles (bugs en cours de production); si vous voulez des jointures de tables, de le faire de façon explicite (joindre... sur...) et d'éviter votre auto les maux de tête
    • pourriez-vous être plus précis sur implicites et explicites des jointures "n'étant pas le même"?
    • Encore une fois, c'est lorsque l'on travaille avec des valeurs null, généralement avec des jointures sur plusieurs colonnes, et certaines de ces valeurs sont nulles, vous obtiendrez des résultats différents (par exemple: vide vs non vide) en fonction de qui vous unissent utilisation
    • est-il un gain de performance en utilisant join on au lieu d'utiliser WHERE?
    • pas de
    • Jointure implicite (,) est exactement la même que la CROIX REJOINDRE et (INTÉRIEURE) de REJOINDRE SUR 1=1 sauf qu'il y a de priorité moindre. (EXTÉRIEUR) - à GAUCHE/à DROITE/à PLEINE Rejoint diffèrent (INTÉRIEURE) JOIN (ils peuvent ajouter des lignes avec des valeurs Null). Vous n'avez qu'à utiliser dans les Jointures avant les Jointures EXTERNES si vous n'utilisez pas une sous-sélection, OÙ à la place. (@BlackTigerX est fausse.)
    • Ce ne sont PAS des synonymes dans MySQL, MySQL optimiseur de choisir votre ordre de jointure si vous fournissez explicitement contre optimisée pour la précédente version de MySQL
    • vous dites que les deux requêtes à partir de l'op donnerait des différents plans?

    InformationsquelleAutor Quassnoi
  2. 164

    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.

    De base d'une requête SELECT est ceci:

    SELECT stuff
FROM tables
WHERE conditions

    La clause SELECT nous dit ce nous sommes de retour; la clause from nous dit où nous sommes en train de partir, et la clause where nous dit qui ceux que nous obtenons.

    JOINTURE est 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 débordait du qui et la où-à partir de; c'est pourquoi la syntaxe de JOINTURE est préféré.

    • Merci pour clarifier la raison pour laquelle jointure interne est préféré Carl. Je pense que votre sna était implicite dans les autres, mais explicite, est généralement mieux (oui, je suis un fan de Python).
    • La sémantique de on et OÙ signifie que, pour les Jointures après la dernière JOINTURE EXTERNE il n'a pas d'importance que vous utilisez. Bien que vous caractériser en tant que partie de la JOINTURE, c'est aussi un filtrage après un produit Cartésien. les Deux et OÙ filtre un produit Cartésien. Mais que ce soit SUR ou une sous-sélection avec l'endroit OÙ doit être utilisé avant la dernière JOINTURE EXTERNE. (Les jointures ne sont pas "sur" colonne de paires. Toutes les deux tables peuvent être réunis SUR n'importe quelle condition. C'est juste une façon d'interpréter Rejoint SUR l'égalité des colonnes en particulier.)
    InformationsquelleAutor Carl Manaster
  3. 126

    Appliquer des instructions conditionnelles dans les SUR /OÙ

    Ici, j'ai expliqué à propos de la logique de traitement de la requête de mesures.

    De 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ée presque 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 <join_condition> est VRAI, sont insérés pour VT2.

    3. EXTERNE (join): 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 <where_condition> 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. : L'AYANT filtre est appliqué à VT6. Seuls les groupes pour lesquels l' <having_condition> 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. 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 améliore les performances. Après que seul le OÙ la condition s'appliquera conditions de filtre.

    (Application des instructions conditionnelles dans les SUR /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)

    • "Donc, (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." Pas nécessairement. L'article est sur le logique commander du traitement. Quand vous dites que l'un particulier de la mise en œuvre permettra de faire une chose avant que toute autre chose, vous parlez de la mise en œuvre commander du traitement. Les implémentations sont autorisés à faire les optimisations qu'ils aiment, tant que le résultat est le même que si la mise en œuvre a suivi la logique de commande. Joe Celko a beaucoup écrit à ce sujet sur Usenet.
    • JOIN) SUR filtrent les données ... avant d'appliquer la clause where ... ce qui améliore les performances." Bon point. "Après que seul le OÙ la condition s'appliquera conditions de filtre" en Ce qui concerne la clause HAVING?
    • Cette revendication par rafidheen est faux. Voir "optimisation de jointure" dans le manuel. Aussi mes autres commentaires sur cette page. (Et MikeSherrill'CatRecall"s.) Une telle "logique" des descriptions de décrire le résultat de la valeur, pas la façon dont il est en fait calculé. Et la mise en œuvre de ce comportement n'est pas garanti de ne pas changer.
    InformationsquelleAutor rafidheen
  4. 60

    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 la WHERE de la clause et de la INNER JOIN, de sorte que même INNER JOIN requêtes avec 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 fabrication INNER JOIN relativement "incomplet" et de mettre certains de ces critères dans les 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 elle dépend, bien sûr.

    • Votre premier extrait certainement me fait mal au cerveau. Personne ne fait cela? Si je rencontre quelqu'un qui le fait, est-il ok pour moi pour le battre sur la tête?
    • - Je trouver les critères où il fait le plus de sens. Si je me joins à une temporellement cohérente instantané de la table de recherche (et je n'ai pas vue ou de l'UDF, qui applique à la sélection d'une date valide), je vais inclure la date d'entrée en vigueur de la jointure et non pas dans le, parce que c'est moins susceptibles d'obtenir accidentellement supprimé.
    • mais il est rare de voir ce type de syntaxe de jointure dans les Jointures internes, il est assez commun pour le DROIT Rejoint et GAUCHE REJOINT -- spécifier plus en détail dans le prédicat de jointure élimine le besoin d'une sous-requête et d'éviter que votre jointures externes malencontreusement transformé en des Jointures internes. (Si je suis d'accord que pour les Jointures internes, je l'avais presque toujours mis de c.État = 'NY' dans la clause where)
    • J'ai vraiment le faire! Et je suis d'accord avec Cade ... je suis curieux de savoir si il y a un décent de raison de ne pas
    InformationsquelleAutor Cade Roux
  5. 29

    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.

    • Je ne pouvais pas être plus en désaccord. La syntaxe de JOINTURE est extrêmement long et difficile à organiser. J'ai beaucoup de requêtes de se joindre à 5, 10, voire 15 de tables à l'aide de la clause where rejoint et ils sont parfaitement lisibles. La réécriture d'une telle requête à l'aide d'une syntaxe de JOINTURE résultats dans un brouillage des mess. Qui va juste pour montrer il n'y a pas de bonne réponse à cette question et qu'il dépend plus de ce que vous êtes à l'aise avec.
    • Noah, je pense que vous pourriez être en minorité ici.
    • Je reçois +1 à matt et à Noé. J'aime la diversité :). Je peux voir où Noé est à venir à partir d'; inner join n'ajoute rien de nouveau à la langue, et est certainement plus verbeux. D'autre part, il peut rendre votre " où " la condition beaucoup plus courte, ce qui signifie généralement qu'il est plus facile à lire.
    • Personnellement, je aller pour des raisons de lisibilité sur la concision
    • Je suppose que tout sane SGBD serait de traduire les deux requêtes dans le même plan d'exécution; cependant, en réalité, chaque SGBD est différente, et la seule façon de le savoir est d'examiner le plan d'exécution (c'est à dire, vous aurez à tester vous-même).
    • Est-il vrai que @rafidheen suggéré dans une autre réponse (celle avec la séquence détaillée de l'exécution SQL) qui Rejoint sont filtrées un à la fois, de réduire la taille de rejoindre opertations quand par rapport à un cartésien se joindre à 3 ou plus tableaux de, avec la OÙ filtre appliqué rétroactivement? Si oui, proposer de REJOINDRE les offres amélioration de la performance (ainsi que les avantages en gauche/droite rejoint, comme l'a également souligné une autre réponse).
    • Non, il n'est pas vrai. Lire à propos de l'optimisation dans le manuel & lire des manuels re logique & physique relationnelle optimisation de la requête.

    InformationsquelleAutor matt b
  6. 25

    Je vous ferais également remarquer que l'utilisation de l'ancienne syntaxe est plus sujette à l'erreur. Si vous utilisez des jointures internes, sans une clause, vous obtiendrez une erreur de syntaxe. Si vous utilisez l'ancienne syntaxe et d'oublier l'une des conditions de jointure dans la clause where, vous obtiendrez une jointure croisée. Les développeurs souvent résoudre ce problème en ajoutant le mot-clé distinct (plutôt que de fixer le rejoindre parce qu'ils ne réalisent pas le rejoindre lui-même est cassé) qui peuvent apparaître à guérir le problème, mais va ralentir la requête considérablement.

    De plus pour l'entretien, si vous avez une jointure croisée dans l'ancienne syntaxe, comment le mainteneur savoir si vous en avez un (il y a des situations où les jointures croisées sont nécessaires) ou si c'était un accident qui doit être fixée?

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

    Plus (personnels coup de gueule ici), le standard à l'aide de l'explicite rejoint plus de 20 ans, ce qui signifie implicite de la syntaxe de jointure a été dépassée pendant ces 20 années. Voulez-vous écrire le code de l'application à l'aide de la syntaxe qui a été dépassée pendant 20 ans? Pourquoi voulez-vous écrire de code de base de données qui est?

    • Alors que je suis entièrement d'accord explicite, les Jointures, il y a des cas où vous avez juste besoin d'utiliser l'ancienne syntaxe. Un exemple réel: ANSI JOINDRE a dans Oracle uniquement dans la version 9i qui a été publié en 2001, et jusqu'à ce qu'il y a un an (de 16 ans à partir du moment où la norme a été publiée), j'ai eu à soutenir un tas de 8i installation pour laquelle nous avons dû libérer les mises à jour critiques. Je ne voulais pas maintenir deux ensembles de mises à jour, de sorte que nous avons développé et testé les mises à jour à l'encontre de toutes les bases de données, y compris 8i, ce qui signifiait que nous n'avons pas pu utiliser les Jointures ANSI.
    • +1 point intéressant lorsque vous signaler que le sintax sans JOINTURE INTERNE est plus sujette aux erreurs. Je suis confus au sujet de votre dernière phrase, quand vous dites "...le standard en utilisant les jointures explicites est de 17 ans." alors, êtes-vous alors ce qui suggère d'utiliser la JOINTURE INTERNE de mot ou pas?
    • Demaio, oui toujours utiliser une JOINTURE INTERNE ou REJOINDRE (ces deux sont les mêmes)ou une JOINTURE GAUCHE ou à DROITE ou REJOINDRE la CROIX REJOINDRE et de ne jamais utiliser l'implicite virgule rejoint.
    • "Pourquoi voulez-vous écrire de code de base de données qui est [20 ans]?" - Je remarque vous écrire du SQL à l'aide de HAVING qui a été "dépassé" depuis SQL commencé à prendre en charge les tables dérivées. Je remarque aussi que vous n'utilisez pas NATURAL JOIN même si je dirais qu'elle a fait INNER JOIN "dépassé". Oui, vous avez vos raisons (pas besoin de les citer à nouveau ici!): mon point est, ceux qui aiment l'aide de l'ancienne syntaxe ont leurs raisons et l'âge relatif de la syntaxe est de si peu d'importance.
    • Les Jointures naturelles ne sont pas pris en charge dans la base de données que j'utilise. Je ne comprends pas pourquoi AVOIR est remplacé par les tables dérivées, veuillez expliquer, je voudrais vraiment être intéressé. Cependant, je n'ai jamais vu quelqu'un qui utilise implicite rejoint donner une raison de les utiliser qui n'est pas,"C'est ce que je suis habitué." Si vous en avez un, je voudrais l'entendre. Il n'y a aucun avantage technique que je connais pour une jointure implicite sur une jointure interne. Il y a des inconvénients techniques, car implicite rejoint peut conduire à de mauvaises ensembles de résultats en raison de non-identifiés croisée accidentelle des jointures qui ne sont pas possible à l'aide de la syntaxe inner join.
    • Il est particulièrement important que de nouvelles personnes à SQL éviter implicite rejoint, ils sont les personnes qui obtiennent de mauvais résultats parce qu'ils ne comprennent pas adhérer à des concepts. Et vous êtes toujours écrit les conditions de jointure dans la clause where de sorte que vous économiser de rien sauf le temps qu'il faut pour écrire le mot de jointure. Étant donné que vous écrivez les conditions plus tard dans la requête, il a probablement fait prend moins de temps thanjumping en haut et en bas dans la requête pour ajouter la clause where comme vous l'ajouter à la jointure. La je suis trop fatigué argument est stupide. Vous pouvez écrire rejoint aussi facilement ou plus facilement qu'une jointure implicite.
    • N'était pas à la recherche d'un argument, vraiment si vous voulais des infos de moi. Mais je maintiens que "périmée depuis 20 ans" est une mauvaise défense et de l'original de mes commentaires.
    • OÙ est encore dans la norme (montrez-moi où il n'est pas). Donc, rien de désuet, apparemment. Aussi, plutôt que de fixer le rejoindre" montre-moi un développeur qui doit être gardé hors de Sgbd en général, présent à l'écart.
    • onedaywhen: "par rapport à l'âge de la syntaxe" est de la "pertinence". Usu., une nouvelle syntaxe / caractéristique est censée être plus efficace et/ou de lecture (dans ce cas, surtout le dernier, mais aussi, comme @HLGEM mentionnés, même les anciens aussi loin que de taper moins due à sauter partout), que les plus âgés de la syntaxe qui est fonctionnellement équivalent.
    • A. Erhard: Le fait qu'une syntaxe (/ fonctionnalité) "est encore dans la norme" (soutenu,) est un mauvais moyen de défense pour l'utiliser. Il existe d'innombrables exemples de cas où une ancienne syntaxe (/ fonctionnalité) "est encore dans la norme" (soutenu,) principalement, sinon uniquement, pour des raisons de compatibilité ascendante. De Plus, HLGEM n'a jamais dit que la WHERE forme n'est plus dans la norme, mais simplement que la JOIN forme (plus probable et par la plupart des comptes destinés à être "mieux") a été autour pendant beaucoup de temps pour réduire de manière significative, si ce n'est, d'éliminer les raisons (c'est à dire de travailler avec le code existant) d'utiliser l'ancien formulaire.

    InformationsquelleAutor HLGEM
  7. 12

    Ils ont une autre forme lisible par l'homme de sens.

    Toutefois, selon l'optimiseur de requête, ils peuvent avoir le même sens pour la machine.

    Vous devriez toujours code soit lisible.

    C'est-à-dire, si c'est un construit-dans la relation, l'utilisation explicite de jointure. si vous faites une comparaison sur que faiblement sur les données, utilisez la clause where.

    InformationsquelleAutor John Gietzen
  8. 11

    SQL:2003 modifié certaines règles de priorité si une instruction de JOINTURE est prioritaire sur une "virgule" de jointure. Cet état de fait peut modifier les résultats de votre requête, selon la façon dont il est installé. Cette cause de certains problèmes pour certaines personnes lorsque MySQL 5.0.12 passé à adhérer à la norme.

    Donc dans votre exemple, vos requêtes fonctionnent de la même. Mais si vous avez ajouté un troisième tableau:
    SELECT ... from table1, table2 REJOINDRE tableau3 SUR ... OÙ ...

    Avant MySQL 5.0.12, table1 et table2 serait rejoint d'abord, puis tableau3. Maintenant (5.0.12 et sur), table2 et tableau3 sont rejoint d'abord, puis de table1. Il n'est pas toujours changer les résultats, mais il peut et on ne peut même pas s'en rendre compte.

    Je n'ai jamais utiliser la "virgule" de la syntaxe de plus, en optant pour le second exemple. C'est beaucoup plus lisible de toute façon, les conditions de JOINTURE sont avec les Jointures ne sont pas séparées dans une requête distincte de la section.

    • Le Standard SQL n'a pas changé. MySQL est tout simplement faux & maintenant est juste. Voir le manuel MySQL.
    InformationsquelleAutor Brent Baisley
  9. 4

    Je sais que vous parlez de MySQL, mais de toute façon:
    Dans Oracle 9 jointures explicites et implicites rejoint serait de générer des différents plans d'exécution. Autant que je sache qui a été résolu dans Oracle 10+: il n'y a pas plus de différence.

    InformationsquelleAutor João Marcus
  10. 1

    ANSI syntaxe de jointure est nettement plus portables.

    Je vais à travers une mise à niveau de Microsoft SQL Server, et j'aimerais également mentionner que l' =* et *= syntaxe des jointures en SQL Server n'est pas prise en charge (sans mode de compatibilité) pour sql server 2005 et versions ultérieures.

    • Même dans SQL Server 2000, = et = peut donner de mauvais résultats et ne doivent jamais être utilisés.
    • *= et =* n'ont jamais été ANSI et n'ont jamais été une bonne notation. C'est pourquoi, en était besoin-pour les Jointures EXTERNES en l'absence de les sous-sélections (qui a été ajouté dans le même temps, de sorte qu'ils ne sont pas réellement nécessaires en CROIX & Jointures internes.)
    InformationsquelleAutor Benzo