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

Bonjour,

voici 2 tables :

Code:

---

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:

---

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.

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

Bonjour LaurentSC

Citation:

---

Envoyé par laurentSc

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 :P

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.

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:

---

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";

---

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:

---

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' ;

---

Merci du conseil.
Et pourquoi plutôt des simples quotes autour des constantes ?

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)

Ah OK, mais apparemment, on est obligé de mettre des quotes inversées autour des noms de table, ou rien :

Code:

---

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...

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 ?

@+

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:

---

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:

---

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 :).

Citation:

---

Envoyé par Artemus24

Salut Escartefigue.


Je pense que tu dois confondre avec Micrososft SQL Server.

---

Non, c'est bien la norme SQL !

Pièce jointe 591764

Citation:

---

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 +

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. :mouarf:

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, ... .

@+

Citation:

---

Envoyé par Artemus24

... 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 +