Create temporary table avec KEY

Bonjour

Je sens que je vais encore me faire taper sur les doigts comme un bambino dans le forum SQL Mais c'est pas grave .... apres tout un forum ca permet aussi de poser des questions quand on ne trouve pas de reponse non ?

J'aimerais ajouter une clef lors de la creation d'une table temporaire a partir d'un query? Mais je me perds dans la syntaxe

J'essaye ceci (pseudocode) mais je me fais jeter

Est-ce possible ?
Quelle serait la bonne syntaxe ?

Merci de votre aide

Code:

---

1 2 3 4 5 6 7 8 9

drop table if exists tempo; create temporary table tempo SELECT A, B, count(C), KEY k (B) FROM address group by A;

---

CREATE TABLE AS

Il me semble ! :p

Non pas vraiment

la syntaxe

Code:

---

create temporary table machin

---

est tout a fait acceptée et marche tres bien

C'est le KEY qui pose problème

Ah, désolé, je n'ai jamais fait de tables temporaires ! Peut-être après le GROUP BY ?

Mais je parles dans le vide, ce ne sont que des suppositions !

Bon courage !

D'après la doc MySQL, ce serait plutôt :

Code:

---

1 2 3 4 5 6 7 8 9

DROP TABLE IF EXISTS tempo; CREATE TEMPORARY TABLE tempo KEY k (B) SELECT A, B, count(C), FROM address GROUP BY A, B;

---

A voir avec votre SGBD si la syntaxe est identique.
J'ai ajouté B au GROUP BY sinon la valeur de B est la première valeur qu'il trouvera au changement de A. C'est plus conforme à la norme SQL comme ça.

Merci CinePhil

J'ai essayé mais toujour le meme probleme

Voici la syntaxe reelle (en MySql)

Code:

---

1 2 3 4 5 6 7 8 9

drop table if exists tempo; CREATE TEMPORARY TABLE `tempo` key k (address.Plaats) SELECT sum(ritstat.gewicht) as gewicht, address.Plaats FROM ritstat Inner Join address ON ritstat.addrID = address.addrID group by Plaats;

---

Si j'enleve le KEY ca va tres bien !

1ère idée :
Remplacer

Code:

---

KEY k (address.Plaats)

---

Par :

Code:

---

KEY k (Plaats)

---

En effet, le résultat du SELECT va nommer la colonne Plaats et non pas address.Plaats.

2ème idée :
Le faire en deux fois...

Code:

---

1 2 3 4 5 6 7 8 9 10 11

DROP TABLE IF EXISTS tempo; CREATE TEMPORARY TABLE `tempo` SELECT sum(ritstat.gewicht) AS gewicht, address.Plaats FROM ritstat INNER JOIN address ON ritstat.addrID = address.addrID GROUP BY Plaats;   ALTER TABLE tempo ADD KEY k (Plaats);

---

Bonsoir, Cinephil :coucou:,

Mais cela me semble une utopie !!! Je laisse des pro du SQL répondre concrètement mais si MySql laisse faire cela ! J'ai peur !

;)

C'est normal que vous n'arriviez à rien. KEY tout seul ne fait pas partie du SQL. En revanche PRIMARY KEY oui. KEY tout seul est une bêrise de plus de MySQL sans ddoute pour intoduire la confusion.

Si vous voulez créer une table temporaire dotée d'une clef PRIMAIRE il faut faire une contrainte de clef primaire et non KEY tout seul.
Il semble que KEY tout seul, dans la syntaxe stupide de MySQL signifie CREATE INDEX !

Donc on reprend :

Citation:

---

J'aimerais ajouter une clef lors de la creation d'une table temporaire a partir d'un query? Mais je me perds dans la syntaxe

---

Code:

---

1 2 3 4 5 6 7 8

CREATE TEMPORARY TABLE tempo AS SELECT A, B, count(C), FROM address GROUP BY A, B;   ALTER TABLE tempo ADD CONSTRAINT PK_tempo PRIMARY KEY (A, B);

---

Maintenant si vous voulez un index sur cette table :

Code:

---

CREATE INDEX...

---

A +

Bonjour chtulus

pourquoi une utopie ?
Pourquoi avoir peur ?

Il me semble asser naturel de pouvoir ajouter un index a une table temporaire, quelle que soit la syntaxe non ? pourquoi en aurait tu peur ?

La suggestion de cinePhil de le faire en deux fois et la bonne !

Code:

---

1 2	ALTER TABLE tempo ADD KEY k (Plaats);

---

La declaration address.plaats ou plaats tout court ne change rien j'avais deja essayé

Il semble que MySql n'accepte pas de creer un index a la volée pendant la creation d'une table resultat d'un query.

Mais la syntaxe ci apres est tout a fait fonctionelle lors de la creation simple de tables

Code:

---

1 2 3 4 5 6 7 8 9

CREATE TABLE IF NOT EXISTS arf ( DsetId bigint(10) default NULL, SecId bigint(10) default NULL, AreItmId bigint(10) default NULL, FacItmId bigint(10) default NULL, KEY AreIdx (AreItmId), KEY Face (FacItmId) ) TYPE=MyISAM;

---

Je sais que SqlPRO fait une allergie a MySQL comme d'autres font des allergies a Microsoft ou Apple ou a je ne sais quoi mais toutes ces choses ont une existence plus qu'evidente avec leurs defauts et leur qualités

Des dizaines de millions d'utilisateurs utilisent Microsoft
Des millions utilisent MySql depuis 1995

SUN a acheté MySQl pour 1 milliard de dollards

S'evertuer a dire que tout ca est stupide et ne vaut rien n'est pas une vision tres réaliste !
Ni constructive ....

Bonjour,

Ben comme la si bien souligné SQLPro, l'utilisation de KEY seul me semblait absurde mais j'en étais pas sur ne connaissant pas bien MySQL et sachant qu'il est capable de tout! :mouarf: Mais c'est un autre débat...

;)

Salut !

@olibara :
Enlève les mots bêrise et stupide du post de SQLPro. Ca te permettra de mieux prendre le message principal :
- Le concept de key est spécifique à MySQL. Cela dit, il ont fait l'effort de "compatibiliser" en permettant également la syntaxe CREATE INDEX
(Enfin, je suppose que ça s'est passé dans cet ordre historiquement)
- Utiliser la syntaxe CREATE INDEX (si c'est possible dans ton cas de figure) te permettra de te faire comprendre par tout le monde facilement, vu qu'on n'est pas sur le forum special MySQL, mais sur le forum SQL tout court.
Bien entendu, cela te permettra aussi de très facilement passer d'un SGBD à un autre, améliorer la compatibilité de ton code avec les autres SGBD, mais ça je suppose que tu dois être au courant...

@SQLPro : eh oui, quand on blinde son post avec des insultes, on braque les gens, et le message qu'on voulait faire passer se perd dans la nature... (étonnant, hein ?)

EDIT :
@Cthulus : pareil, je connais pas les spécificités de syntaxe MySQL... mais j'ai cherché sur le net :)

Merci pour ce message tres pertinent Packmann

Ca fait plaisir de voir des réponses réfléchies et pragmatiques

Merci aussi a l'aide de tous et CinéPhil qui a trouvé la bonne methode.

Je vous rapelle que nous sommes sur un forum consacré au langage SQL qui est une norme mainte fois mise à jour
SQL 1 : 1986
SQL 2 : 1992
SQL:1999
SQL:2003
SQL:2008
Si vous postez sur ce forum, c'est que vous voulez des précisions sur ce langage. J'estime donc parfaitement normal ce rappel à l'ordre sur MySQL qui, comme Oracle met en place une syntaxe anormative.
Maintenant si vous voulez parler du dialecte MySQL comme certains parle le patois landais, vous devez poster sur le forum MySQL.

Rassurez vous il m'arrive de dire du mal aussi de MS SQL Server sur ce forum, par exemple quand je voit l'emploi qui est fait du fameux TOP propre au dialecte Transact SQL et qui est une hérésie !

Reste que PostGreSQL, IBM Db2 ou SQL Server sont très proche de la norme, voici aussi pourquoi j'en dit moins de mal que pour MySQL qui en est très loin !
Il n'y a pas d'aversion de ma part à MySQL, même si je donne l'impression d'être contre. Il m'est même arrivé de le préconiser dans certains projets...

A +

A +

Comment se fait-il qu'en 2009 nous ne parlons plus Latin ?

Quelles sont les hérétiques qui on fait dériver cette belle langue normative ?

Se figer dans les normes, c'est aussi renoncer a vivre et evoluer...
Mais c'est un autre débat

Comme le dit tres bien pacmann, qualifier de betise et stupidité ce qui sort du cadre qu'on s'est choisi polue toute discussion !

Oui, certes olibara, on ne parle plus latin...
Par contre, on parle anglais pour arriver à ce comprendre.

Tu peux aussi comparer avec les mathématiques, où on essaie de tous adopter les même notations, et utiliser les mêmes mécanismes.

SQL n'est pas figé, il évolue. Et comme dirait SQLPro, il y a des gens de tous les SGBD qui participent à l'évolution de cette norme.

Le fait en soi que les SGBD innove est tout à fait constructif ! C'est comme ça qu'on avance... ce n'est pas la norme SQL qui fait de la R&D, ce sont bien les différents éditeurs !

Et je t'assure que perso, je suis assez fan des petites conneries Oracle ! ;)
("Connerie" étant employé affectueusement bien sûr)
Mais comme dit, il y a deux points importants :
- Lorsqu'une notion existe pour un SGBD dans la version ET dans la version normée, cela relève justement de la capacité d'adaptation de passer à la norme pour les raisons sus-citées (Je rappelle qu'Oracle conseille d'abandonner la syntaxe native (+) contre la syntaxe LEFT OUTER JOIN par exemple)
- On n'est pas contre les spécificités des SGBD, mais celles-ci sont simplement traitées dans les autres parties de ce forum.

Maintenant, comme dit, je comprends parfaitement qu'on puisse se retrouver ici "à l'insu de son plein gré". Et bien entendu, on peut discuter de tout ça calmement en restant amis (à condition que nous soyions tous de bonne foi)
;)

La bonne fois, moi, jamais... ;-)
Je suis ni adepte du consensus mou, ni adepte du politiquement correct ! :mouarf:

A +