IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Requêtes MySQL Discussion :

Requête SELECT à partir de données dans 2 tables


Sujet :

Requêtes MySQL

  1. #1
    Membre expert

    Homme Profil pro
    Webmaster débutant perpétuel !
    Inscrit en
    octobre 2006
    Messages
    8 274
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Webmaster débutant perpétuel !
    Secteur : Industrie

    Informations forums :
    Inscription : octobre 2006
    Messages : 8 274
    Points : 3 896
    Points
    3 896
    Billets dans le blog
    1
    Par défaut Requête SELECT à partir de données dans 2 tables
    Bonjour,

    voici 2 tables :
    Code sql : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    DROP TABLE IF EXISTS `customer`;
    CREATE TABLE `customer` (
      `customer_id` smallint NOT NULL AUTO_INCREMENT,
      `customer_login_id` int DEFAULT NULL,
      `country_key` smallint DEFAULT NULL,
      `organization` varchar(50) COLLATE utf8_bin DEFAULT NULL,
      PRIMARY KEY (`customer_id`),
      UNIQUE KEY `customer_login_id_UNIQUE` (`customer_login_id`)
    ) ENGINE=InnoDB AUTO_INCREMENT=61 DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

    Code sql : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    DROP TABLE IF EXISTS `country`;
    CREATE TABLE `country` (
      `country_key` smallint NOT NULL AUTO_INCREMENT,
      `country` varchar(30) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL DEFAULT '',
      `region` varchar(30) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT '',
      PRIMARY KEY (`country_key`),
      UNIQUE KEY `uk_country` (`country`)
    ) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

    Je souhaite extraire les données customer_login_id, organization et country. Donc les 2 premières colonnes appartiennent à la première table et la 3e colonne à la seconde table.
    Je crois savoir qu'un bug de MySQL nécessite de passer par une table temporaire. Néanmoins, je n'y parviens pas. Merci de votre aide.
    Il vaut mieux viser la perfection et la manquer que viser l'imperfection et l'atteindre. - Bertrand Russell

  2. #2
    Modérateur
    Avatar de al1_24
    Homme Profil pro
    Ingénieur d'études décisionnel
    Inscrit en
    mai 2002
    Messages
    8 647
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur d'études décisionnel
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 8 647
    Points : 28 647
    Points
    28 647
    Par défaut
    Où rencontres-tu une difficulté dans cette requête ?
    C'est juste une jointure simple entre ces deux tables. Au pire une jointure externe si la colonne customer.country_key est vide ou mal renseignée (en effet, en l'absence de contrainte d'intégrité référentielle, la validité de cette donnée ne peut être assurée par la base de données).
    Quant à la nécessité de passer par une table temporaire, j'aimerais que tu nos donnes la source de tes informations...

    Voici un bon tutoriel pour comprendre les jointures : LE SQL de A à Z : 3e partie - les jointures
    Modérateur Langage SQL
    Règles du forum Langage SQL à lire par tous, N'hésitez pas à consulter les cours SQL
    N'oubliez pas le bouton et pensez aux balises
    [code]
    Si une réponse vous a aidé à résoudre votre problème, n'oubliez pas de voter pour elle en cliquant sur
    Aide-toi et le forum t'aidera : Un problème exposé sans mentionner les tentatives de résolution infructueuses peut laisser supposer que le posteur attend qu'on fasse son travail à sa place... et ne donne pas envie d'y répondre.

  3. #3
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    6 770
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 6 770
    Points : 21 250
    Points
    21 250
    Billets dans le blog
    2
    Par défaut
    Bonjour LaurentSC

    Citation Envoyé par laurentSc Voir le message
    Je crois savoir qu'un bug de MySQL nécessite de passer par une table temporaire. Néanmoins, je n'y parviens pas. Merci de votre aide.

    MySQL n'est pas exempt de bug, mais heureusement pas celui-ci

    Peut-être y a-t-il confusion avec les CTE (Common Table Expression) qui ne sont pas des tables temporaires mais des tables dérivées externalisées, dont la prise en compte par MySQL n'est apparue qu'avec la V8 et dont vous n'avez pas besoin ici.

  4. #4
    Membre expert

    Homme Profil pro
    Webmaster débutant perpétuel !
    Inscrit en
    octobre 2006
    Messages
    8 274
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Webmaster débutant perpétuel !
    Secteur : Industrie

    Informations forums :
    Inscription : octobre 2006
    Messages : 8 274
    Points : 3 896
    Points
    3 896
    Billets dans le blog
    1
    Par défaut
    En fait la seule difficulté était de penser qu'on pouvait tout simplement résoudre le problème par une jointure. Il faut dire que je cherchais à m'inspirer d'un code existant qui avait nécessité le recours à une table externe (je serais pas capable d'expliquer pourquoi). En attendant, ici, pas besoin effectivement :
    Code sql : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
            SELECT cu.customer_login_id,cu.organization,co.country FROM `customer` AS cu JOIN `country` AS co ON cu.country_key=co.country_key WHERE co.country="France";
    Il vaut mieux viser la perfection et la manquer que viser l'imperfection et l'atteindre. - Bertrand Russell

  5. #5
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    6 770
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 6 770
    Points : 21 250
    Points
    21 250
    Billets dans le blog
    2
    Par défaut
    Une requête est bien plus facile à lire et donc à comprendre et à maintenir, quand elle est formatée avec soin.
    De plus, les constantes doivent être encadrées par des quotes simples et non pas doubles.

    Par exemple :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
       SELECT cu.customer_login_id
             , cu.organization
             , co.country 
       FROM `customer` AS cu 
       JOIN `country`  AS co
         ON co.country_key=cu.country_key 
       WHERE co.country='France'
       ;

  6. #6
    Membre expert

    Homme Profil pro
    Webmaster débutant perpétuel !
    Inscrit en
    octobre 2006
    Messages
    8 274
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Webmaster débutant perpétuel !
    Secteur : Industrie

    Informations forums :
    Inscription : octobre 2006
    Messages : 8 274
    Points : 3 896
    Points
    3 896
    Billets dans le blog
    1
    Par défaut
    Merci du conseil.
    Et pourquoi plutôt des simples quotes autour des constantes ?
    Il vaut mieux viser la perfection et la manquer que viser l'imperfection et l'atteindre. - Bertrand Russell

  7. #7
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    6 770
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 6 770
    Points : 21 250
    Points
    21 250
    Billets dans le blog
    2
    Par défaut
    Parce que les doubles quotes servent à délimiter les noms d'objets : noms de colonnes, de tables, de vues etc.

    MySQL utilise une syntaxe particulière et non normalisée avec les quotes inversées, mais la norme c'est les doubles quotes pour les noms d'objets (obligatoires si vous utilisez des noms réservés SQL)

  8. #8
    Membre expert

    Homme Profil pro
    Webmaster débutant perpétuel !
    Inscrit en
    octobre 2006
    Messages
    8 274
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Webmaster débutant perpétuel !
    Secteur : Industrie

    Informations forums :
    Inscription : octobre 2006
    Messages : 8 274
    Points : 3 896
    Points
    3 896
    Billets dans le blog
    1
    Par défaut
    Ah OK, mais apparemment, on est obligé de mettre des quotes inversées autour des noms de table, ou rien :

    Code sql : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
       SELECT cu.customer_login_id
             , cu.organization
             , co.country 
       FROM customer AS cu 
       JOIN country  AS co
         ON co.country_key=cu.country_key 
       WHERE co.country='France';
    car avec les doubles quotes, il rale...
    Il vaut mieux viser la perfection et la manquer que viser l'imperfection et l'atteindre. - Bertrand Russell

  9. #9
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    février 2011
    Messages
    4 820
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : février 2011
    Messages : 4 820
    Points : 13 826
    Points
    13 826
    Par défaut
    Salut Escartefigue.

    Citation Envoyé par Escartefigue
    Parce que les doubles quotes servent à délimiter les noms d'objets : noms de colonnes, de tables, de vues etc.
    Je pense que tu dois confondre avec Micrososft SQL Server.

    Les noms des colonnes, tables vues, ... ne sont pas des chaines de caractères.
    Si tu écrits le nom de la table entre apostrophes ou entre guillemets, cela va provoquer une erreur de syntaxe.

    Si tu ne mets rien, il faut faire attention aux mots réservés qui seront interprété en tant que telle.
    Ou bien tu mets les noms entre apostrophes inversés.

    Citation Envoyé par Escartefigue
    MySQL utilise une syntaxe particulière et non normalisée avec les quotes inversées
    Je crois me souvenir que l'apostrophe inversée était déjà utilisé sous DB2 gros système.
    Peux-tu me le confirmer ?

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  10. #10
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    6 770
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 6 770
    Points : 21 250
    Points
    21 250
    Billets dans le blog
    2
    Par défaut
    Bonjour Artemus24,

    Non, je ne confonds pas, je parle de la norme SQL.

    MySQL déroge à la règle en utilisant les quotes inversées

    Ainsi, en MySQL on codera :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    create table `table`(`date` date not null);
    insert into `table` values('2021-02-23');
    select * from `table`;
    Avec MS SQL Server, DB2 ou PostGre on codera :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    create table "table"("date" date not null);
    insert into "table" values('2021-02-23');
    select * from "table"
    SQL Server accepte également les crochets [] en remplacement des doubles quotes

    DB2 n'accepte que la norme, à savoir la double quote

    Le plus simple reste bien entendu d'éviter les noms réservés .

  11. #11
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 571
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 571
    Points : 48 682
    Points
    48 682
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    Salut Escartefigue.


    Je pense que tu dois confondre avec Micrososft SQL Server.
    Non, c'est bien la norme SQL !

    Nom : SQL_identifier_double_quote_standard.jpg
Affichages : 18
Taille : 60,7 Ko

    Je crois me souvenir que l'apostrophe inversée était déjà utilisé sous DB2 gros système.
    Peux-tu me le confirmer ?
    Non, DB2 est hypernormatif puisque c'est IBM qui a inventé le SQL; Donc guillemets et rien d'autre !
    https://www.ibm.com/support/knowledg.../r0000720.html

    Les accents délimitant les identifiants SQL c'est une des grosses merdes pourries de MySQL !

    Pour info SQL Server accepte la norme SQL "toto" mais aussi les crochets [toto] que je trouve épouvantables !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  12. #12
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    février 2011
    Messages
    4 820
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : février 2011
    Messages : 4 820
    Points : 13 826
    Points
    13 826
    Par défaut
    Salut à tous.

    Citation Envoyé par Escartefigue
    Non, je ne confonds pas, je parle de la norme SQL.
    Je croyais que tu parlais de MySql et non de la norme, d'où mon erreur.

    Du coup, je me pose la question de l'origine de l'apostrophe inversée ?

    Citation Envoyé par Escartefigue
    Le plus simple reste bien entendu d'éviter les noms réservés
    N'est-ce pas l'origine de l'introduction de l'encadrement des noms ?

    Citation Envoyé par SQLPRO
    Pour info SQL Server accepte la norme SQL "toto" mais aussi les crochets [toto] que je trouve épouvantables !
    Même avec ton bébé chérie Microsoft SQL Server, tu trouves qu'encadrer les noms avec des guillemets ou des crochets est épouvantable.
    Tu remontes dans mon estime.

    Peut-être qu'une solution aurait été de faire la distinction entre les majuscules pour désigner les mots réservés formant la structure des requêtes et les minuscules pour tout ce qui concerne les noms de table, de colonnes, de vus, ... .

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  13. #13
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 571
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 571
    Points : 48 682
    Points
    48 682
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    ... tu trouves qu'encadrer les noms avec des guillemets ou des crochets est épouvantable.
    Avec des guillemets non, puisque c'est le norme. Avec des crochets, oui, je trouve cela épouvantable, parce que c'est justement pas la norme !

    L'usage de ces délimiteurs d'identifiant est absolument indispensable... en effet certains mots clef de SQL apparaissent au fur et à mesure de l'élaboration de la norme et peuvent entrer en conflit avec des requêtes existantes qu'il faudra corriger.

    Je me souviens qu'avec l'apparition des fonctions fenêtrées, un de mes clients avait une colonne de nom "OVER". En SQL Server 2000, pas besoin de délimiteurs.... mais en version 2005 avec l'apparition de la clause OVER des fonctions fenêtrées, ça plante !

    Bref, correction en urgence de plus de 300 requêtes dans les applications....

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 4
    Dernier message: 09/01/2008, 21h10
  2. Réponses: 5
    Dernier message: 26/01/2007, 09h11
  3. Enregistrer des données dans une table à partir du code
    Par Ragnarok85 dans le forum Access
    Réponses: 4
    Dernier message: 24/01/2007, 14h03
  4. Réponses: 11
    Dernier message: 04/05/2006, 12h50
  5. Réponses: 2
    Dernier message: 15/06/2005, 18h32

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo