Discussion :

[mds084]

Bonsoir,

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

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

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

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]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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]

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

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

[CinePhil]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Sélectionner tout - Visualiser dans une fenêtre à part

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