CREATE TEMPORARY TABLE [Résolu]

[mds084]

Bonsoir,

Je n'arrive pas à faire fonctionner dans mes codes la fonction CREATE TEMPORARY TABLE

Code :

1
2
3
4
5
6
7
8
9
 
$qry = "CREATE TEMPORARY TABLE temp_detail ";
$qry .= "SELECT id_champ, journee FROM `journee` WHERE status = 4 ORDER BY MAJ DESC LIMIT 0, 30;" ;
$qry .= "SELECT * FROM temp_detail" ;
$res = $db->sql_query($qry);
while ($row = $db->sql_fetchrow($res))
{
     bla bla bla
}

cet exemple est tout simple car je n'ai aucun affichage dés que j'utilise CREATE TEMPORARY TABLE.

La requete s'affiche bien dans phpmyadmin mais pas d'affichage sur ma page web.

J'ai aussi affiché la syntax de la requete sur ma page web puis copier sur phpmyadmin pour controle et elle fonctionne.

Je pense que cela doit venir de cette ligne :

Code :

1
2
 
while ($row = $db->sql_fetchrow($res))

Mais je ne trouve rien qui pourrait me donner la solution.
Je suis obligé de faire une table temporaire pour faire des jointures avec des lignes ou le résultat est null. pas de souci avec les jointures car je bloque juste avec le resulat de cette requete.

Merci pour votre aide.

[Tolriq]

Il faut faire 2 requêtes séparées

Ça ne marche pas bien voir pas du tout de mettre plusieurs requêtes avec des ;

Code :

1
2
3
4
5
6
7
8
9
$qry = "CREATE TEMPORARY TABLE temp_detail ";
$qry .= "SELECT id_champ, journee FROM `journee` WHERE status = 4 ORDER BY MAJ DESC LIMIT 0, 30;" ;
$res = $db->sql_query($qry);
$qry = "SELECT * FROM temp_detail" ;
$res = $db->sql_query($qry);
while ($row = $db->sql_fetchrow($res))
{
     bla bla bla
}

En rajoutant bien entendu une gestion d'erreur sur la 1ère requête

[CinePhil]

Déjà qu'il faut éviter de relancer la guerre des étoiles, quel est l'intérêt de faire un SELECT * sur une table temporaire créée par une requête SELECT au lieu de récupérer directement le résultat de cette requête ?

[mds084]

Merci, ca marche, une simple astuce et j'ai galéré pendant 3H hier.

Envoyé par Tolriq

En rajoutant bien entendu une gestion d'erreur sur la 1ère requête

Quelle gestion d'erreur ?
je ne connais pas cela.

Envoyé par CinePhil

Déjà qu'il faut éviter de relancer la guerre des étoiles, quel est l'intérêt de faire un SELECT * sur une table temporaire créée par une requête SELECT au lieu de récupérer directement le résultat de cette requête ?

A rien et c’était qu'un exemple car ma requête fait 4 lignes avec 4 tables avec jointure "LEFT" d’où mon obligation de passer par une table temporaire sinon il me manquait des lignes dans le résultat.

Et je viens de voir que la requête exécute 4 fois plus vite avec cette table temporaire qu'avec 1 seule requête et un résultat incomplet.

Je sélectionne toujours les champs à afficher dans mes requêtes pour optimiser l'affichage de mon site mais merci du lien

[CinePhil]

Envoyé par mds084

A rien et c’était qu'un exemple car ma requête fait 4 lignes avec 4 tables avec jointure "LEFT" d’où mon obligation de passer par une table temporaire sinon il me manquait des lignes dans le résultat.

Si c'est toujours pour finalement n'afficher que le contenu de la table temporaire sans calcul ou autres, ça me semble toujours inutile.

On peut voir le code réel ?

[mds084]

le voici, mais pourquoi voulez vous le voir ?

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
	$qry = "CREATE TEMPORARY TABLE temp_detail ";
	$qry .= "SELECT id_membres, groupe, sum(points) score, count(p.id_match) nb, SUM(if(points = 5,1,0)) P5, SUM(if(points = 4,1,0)) P4,  SUM(if(points = 3,1,0)) P3, SUM(if(points > 0,1,0)) PB
				FROM table1 p, table2 m WHERE p.id_match = m.id_match and groupe = $id and m.champ = $champ and m.jour = $jour GROUP BY id_membres "; 
	$res = $db->sql_query($qry);
	$qry = "SELECT pseudo, score, nb, P5, P4, P3, PB FROM table3 LEFT JOIN temp_detail ON id_pseudo = id_membres WHERE equipe = $id ORDER BY score DESC ";
	$res = $db->sql_query($qry);
	while ($row = $db->sql_fetchrow($res))
	{
		$a++;
		echo "<tr bgcolor=\"#DDEBEE\">	
				<td align=\"center\">  $a </td>
				<td>  $row[pseudo] </td>
				<td align=\"center\"> $row[score] </td>
				<td align=\"center\"> $row[nb] </td>
				<td align=\"center\"> $row[PB] </td>
				<td align=\"center\"> $row[P5] </td>
				<td align=\"center\"> $row[P4] </td>
				<td align=\"center\"> $row[P3] </td>
			</tr>";
	}

Je voulais afficher tous les "pseudo" de la table3 même si il n'y a aucun résultat pour certain, il me faut donc une table temporaire pour faire cela, je n'ai rien trouvé pour éviter la table temporaire.

Je pense aussi que la table temporaire réduit le temps d'affichage même si il y a une autre solution.

[CinePhil]

1) table1, table2, table3
Vachement explicites comme noms de tables ! Je ne voudrais pas avoir à développer un truc utilisant ta BDD !

2) Pourquoi n'utilises-tu pas la jointure normalisée (avec JOIN) dans la première requête alors que tu l'utilises dans la seconde ?

3) Comme tu n'utilises pas "groupe" dans la seconde requête, inutile de le mettre dans le SELECT de la première requête.

4) Tu ne fais la seconde requête que pour récupérer le pseudo du membre qui est dans la table3 ?
Pourquoi ne pas faire ça en une seule requête ?

Et je viens de voir que la requête exécute 4 fois plus vite avec cette table temporaire qu'avec 1 seule requête et un résultat incomplet.

que veux-tu dire par "résultat incomplet" ?

Si, comme je pense l'avoir compris d'après l'utilisation de la variable $id, table3.equipe = "groupe" de la première requête, alors tu dois pouvoir en une seule requête te passer de la condition sur l'équipe :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
SELECT t3.pseudo, tmp.score, tmp.nb, tmp.P5, tmp.P4, tmp.P3, tmp.PB
FROM table3 t3
LEFT OUTER JOIN
(
    SELECT id_membres, 
        sum(points) score, 
        count(p.id_match) nb, 
        SUM(if(points = 5, 1, 0)) P5, 
        SUM(if(points = 4, 1, 0)) P4,  
        SUM(if(points = 3, 1, 0)) P3, 
        SUM(if(points > 0, 1, 0)) PB
    FROM table1 p
    INNER JOIN table2 m ON p.id_match = m.id_match
    WHERE groupe = $id 
        and m.champ = $champ 
        and m.jour = $jour 
    GROUP BY id_membres 
) tmp ON tmp.id_membres = t3.id_pseudo
ORDER BY score DESC

[mds084]

Envoyé par CinePhil

table1, table2, table3
Vachement explicites comme noms de tables ! Je ne voudrais pas avoir à développer un truc utilisant ta BDD !

tu veux aussi ma connexion à ma base sans doute
si tu n'as pas compris que j'ai changé le nom de mes tables, ca devient grave ici.

2) Pourquoi n'utilises-tu pas la jointure normalisée (avec JOIN) dans la première requête alors que tu l'utilises dans la seconde ?

je n'en voyais pas l'utilité mais je suis là pour apprendre.

3) Comme tu n'utilises pas "groupe" dans la seconde requête, inutile de le mettre dans le SELECT de la première requête.

exact.

4) Tu ne fais la seconde requête que pour récupérer le pseudo du membre qui est dans la table3 ?
Pourquoi ne pas faire ça en une seule requête ?

chercher pendant 3 heures avec plusieurs solutions et jamais eu le résultat attendu.

que veux-tu dire par "résultat incomplet" ?

je veux tout les pseudo de la table3 soit affiché dans l'affichage du résultat et pas seulement les membres de la table1, c'est la jointure entre table1 et table3

Si, comme je pense l'avoir compris d'après l'utilisation de la variable $id, table3.equipe = "groupe" de la première requête, alors tu dois pouvoir en une seule requête te passer de la condition sur l'équipe :

je vais tester pour voir si ca fonctionne et si c'est plus rapide.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
SELECT t3.pseudo, tmp.score, tmp.nb, tmp.P5, tmp.P4, tmp.P3, tmp.PB
FROM table3 t3
LEFT OUTER JOIN
(
    SELECT id_membres, 
        sum(points) score, 
        count(p.id_match) nb, 
        SUM(if(points = 5, 1, 0)) P5, 
        SUM(if(points = 4, 1, 0)) P4,  
        SUM(if(points = 3, 1, 0)) P3, 
        SUM(if(points > 0, 1, 0)) PB
    FROM table1 p
    INNER JOIN table2 m ON p.id_match = m.id_match
    WHERE groupe = $id 
        and m.champ = $champ 
        and m.jour = $jour 
    GROUP BY id_membres 
) tmp ON tmp.id_membres = t3.id_pseudo
ORDER BY score DESC

[CinePhil]

Envoyé par mds084

tu veux aussi ma connexion à ma base sans doute

Euh... non, pas spécialement, je risquerais d'avoir envie de tout vérifier et remodéliser !

si tu n'as pas compris que j'ai changé le nom de mes tables, ca devient grave ici.

Wow ! C'est vachement confidentiel une table appelée "membre", "groupe", "equipe", "partie"... Avec ça je vais te piquer ton business !
Par contre ça aide quand même pas mal à la compréhension de la requête pour ceux qui veulent t'aider.

je n'en voyais pas l'utilité mais je suis là pour apprendre.

JOIN est la syntaxe normalisée pour les jointures depuis 1992. L'ancienne syntaxe "FROM plusieurs tables WHERE conditions de jointures" est à abandonner, même si elle fonctionne encore. La séparation des jointures et des restrictions présente de nombreux avantages déjà maintes fois discutés dans nos forums.

[mds084]

Ton code fonctionne sans faire la table temporaire, je n'avais pas trouvé malgré mes nombreux essais.
15 total, Traitement en 0.1239 sec


le code avec la table temporaire est plus rapide comme je l'avais remarqué ce matin
15 total, Traitement en 0.0048 sec.

mon code que j'avais réussi à faire avec 13 résultats affichés sans utiliser INNER JOIN mais seulement des jointures avec WHERE.
13 total, Traitement en 0.0389 sec.

Les jointures sont peut être plus logique pour toi mais sur cet exemple, c'est moins rapide.

j'ai rajouté ceci à ton code WHERE equipe = $id sinon il y avait les 6240 lignes de ma table3

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
SELECT t3.pseudo, tmp.score, tmp.nb, tmp.P5, tmp.P4, tmp.P3, tmp.PB
FROM table3 t3
LEFT OUTER JOIN
(
    SELECT id_membres, 
        sum(points) score, 
        count(p.id_match) nb, 
        SUM(if(points = 5, 1, 0)) P5, 
        SUM(if(points = 4, 1, 0)) P4,  
        SUM(if(points = 3, 1, 0)) P3, 
        SUM(if(points > 0, 1, 0)) PB
    FROM table1 p
    INNER JOIN table2 m ON p.id_match = m.id_match
    WHERE groupe = $id 
        and m.champ = $champ 
        and m.jour = $jour 
    GROUP BY id_membres 
) tmp ON tmp.id_membres = t3.id_pseudo
WHERE equipe = $id
ORDER BY score DESC

Merci pour cet exemple et je le garde au chaud pour une prochaine fois ou ton exemple sera plus approprié.
car juste le code sans la table 3 avec ta jointure INNER JOIN est très rapide.
13 total, Traitement en 0.0014 sec.
comme la mienne sans la jointure INNER. (voir ci dessous)
13 total, Traitement en 0.0013 sec

Pour moi les 2 méthodes sont identiques, quel risque d'utilisé le WHERE au lieu de INNER JOIN.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
 
    SELECT id_membres, 
        sum(points) score, 
        count(p.id_match) nb, 
        SUM(if(points = 5, 1, 0)) P5, 
        SUM(if(points = 4, 1, 0)) P4,  
        SUM(if(points = 3, 1, 0)) P3, 
        SUM(if(points > 0, 1, 0)) PB
    FROM table1 p, table2 m WHERE p.id_match = m.id_match
    and groupe = $id 
        and m.champ = $champ 
        and m.jour = $jour 
    GROUP BY id_membres

[CinePhil]

Les deux syntaxes de jointures seront en principe traitées de la même façon par le SGBD, et heureusement !

Mais je ne compte plus le nombre de requêtes "kimarch'pas" proposées sur nos forums et que j'ai corrigées simplement en les récrivant avec la syntaxe JOIN. La plupart du temps, c'est une condition de jointure manquante ou une seule instance de table utilisée dans deux jointures.

En plus je trouve la syntaxe avec JOIN bien plus claire que l'ancienne car elle permet de bien différencier les conditions de jointure des conditions de restriction.

Et puis merde ! C'est la norme depuis 1992, il est temps de s'y mettre !

[mds084]

Envoyé par CinePhil

Wow ! C'est vachement confidentiel une table appelée "membre", "groupe", "equipe", "partie"... Avec ça je vais te piquer ton business !
Par contre ça aide quand même pas mal à la compréhension de la requête pour ceux qui veulent t'aider.

pas de business sur cette table, c'est du bénévolat, on m'a juste dit un jour de ne pas donner les noms des tables pour éviter des injections par url, tout simplement et désolé d'avoir pris la mouche, cela doit venir de mon age avancé

je vais lire cet article sur les jointures car c'est plus simple pour moi et fonctionne rapidement donc pas chercher plus loin

[CinePhil]

Envoyé par mds084

pon m'a juste dit un jour de ne pas donner les noms des tables pour éviter des injections par url,

Si c'est tout ce qu'on t'a dit pour te protéger des injections, tu peux Googler le sujet pour apprendre que c'est largement insuffisant !

[mds084]

Je viens de lire ton lien et je connaissais déjà et j'ai même passé bien 30 mn dessus pour trouver mon cas sans succès.

Tu m'as donné le bâton pour te faire taper, les exemples de 1 à 7 sont pas les même que ma requête par hasard

Je reconnais que c'est plus logique et plus clair à comprendre quand il y a une erreur mais pas plus pratique à écrire ou c'est une mauvaise habitude que j'ai prise depuis 30 ans, oui j'ai commencé avant 1992 cela doit venir de là.

j'ai plus de connaissance en base ACCESS qu'en base MySQL ou cela fait que 3 ans que j'ai commencé à y travailler dessus.

Par contre personne a répondu à cette remarque et ensuite je met résolu à cette demande.

Merci pour cette discussion intéressante

Envoyé par Tolriq

En rajoutant bien entendu une gestion d'erreur sur la 1ère requête

[CinePhil]

Envoyé par mds084

Tu m'as donné le bâton pour te faire taper, les exemples de 1 à 7 sont pas les même que ma requête par hasard

Hélas, il commence par l'ancienne syntaxe, mais ensuite il écrit en gras :

Dans la mesure du possible, utilisez toujours un opérateur de jointure normalisé Sql2 (mot clef JOIN).
En effet :

• Les jointures faites dans la clause WHERE (ancienne syntaxe de 1986 !) ne permettent pas de faire la distinction de prime abord entre ce qui relève du filtrage et ce qui relève de la jointure.
• Il est à priori absurde de vouloir filtrer dans le WHERE (ce qui restreint les données du résultat) et de vouloir "élargir" ce résultat par une jointure dans la même clause WHERE de filtrage.
• La lisibilité des requêtes est plus grande en utilisant la syntaxe à base de JOIN, en isolant ce qui est du filtrage et de la jointure, mais aussi en isolant avec clarté chaque condition de jointures entre chaque couples de table.
• L'optimisation d'exécution de la requête est souvent plus pointue du fait de l'utilisation du JOIN.
• Lorsque l'on utilise l'ancienne syntaxe et que l'on supprime la clause WHERE à des fins de tests, le moteur SQL réalise le produit cartésiens des tables ce qui revient la plupart du temps à mettre à genoux le serveur !

Et il enchaîne au chapitre III avec la nouvelle syntaxe.

c'est une mauvaise habitude que j'ai prise depuis 30 ans

Je confirme !

j'ai plus de connaissance en base ACCESS qu'en base MySQL ou cela fait que 3 ans que j'ai commencé à y travailler dessus.

Ben justement, sous Access, il me semble me souvenir que quand tu crées une requête en mode graphique et que tu cliques sur le bouton SQL, tu trouves des jointures JOIN !
Par contre, la forêt de parenthèses mises par Access et l'imbrication des JOIN sont une horreur !

Pour la gestion d'erreur, il est d'usage, surtout quand on développe et qu'on est pas sûr que les requêtes fonctionnent, de faire ceci avec l'ancienne méthode :

Code :

$result = mysql_query($sql) or die ("Erreur ! ". mysql_error());

Avec PDO, je ne sais plus comment ça fonctionne mais j'imagine que la gestion d'erreurs classique avec try / catch doit fonctionner et on récupère les erreurs MySQL avec PDO. Voir la doc, ça fait un peu longtemps que je n'ai pas fait ça.

[mds084]

Merci pour ces réponses et l'utilisation du JOIN est identique sous ACCESS mais j'ai toujours eu du mal à faire comme cela car cela fonctionne et comme je raisonne avec les WHERE quand je construit une requête comme un filtre à chaque fois cela me permet de rien oublié.

Le jour ou cela n'est plus permis, j'aurai du boulot à tout réécrire

Code :

1
2
 
$result = mysql_query($sql) or die ("Erreur ! ". mysql_error());

oui, je connais ce controle d'erreur mais je le met jamais car je n'affiche jamais les messages d'erreur et j'ai même une fonction qui les cache si besoin car je travaille qu'avec des "function" que j'appelle au besoin sur ma page.

La page d’affichage est souvent vide et claire et cela permet aussi de faire un break ou on veut pour voir ou le code plante.

Merci, je met résolu