Discussion :

[blaz]

Bonjour,
Voici mon problème :
J'ai une requête SQL qui ramène x lignes. Ces résultats doivent servir à construire une courbe pour un graphique.
x peut varier de 2 à 1000.
Hors l'applet chargée de l'affichage ne gère que 333 valeurs au maximum.
Ma question est :
Comment dans une requête SQL ne ramener que 333 enregistrements max, et que ces enregistrements représentent la 'moyenne' ?

Exemple :
j'ai 1000 enregistrements de retournés:
indice |0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10
-----------------------------------------------------------------
valeur|5.2|1.2|8.5|8.6|8.7|8.8|9.5|9.87|10.2|11.41|12.3

si je fais 1000/333 j'obtiens 3. Donc en ne prenant que les valeurs en pas de 3 je n'aurai que 333 valeurs représentant la moyenne lissée.

indice |0 |3 |6 |9
-----------------------------
valeur|5.2|8.6|9.5|11.41

Admettons que ma requête classique est :

Code :

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

SELECT valeur FROM histoVL WHERE idprod='1458'

Comment la transformer pour n'obtenir qu' un série de valeurs ventilées (comme l'exemple au dessus) ?

Je tourne sous mySQL 4.0.13

Merci

[Balise code ajouté par ZEUSGR]
[Merci de l'ajouter la prochaine fois ]

[WOLO Laurent]

Je propose ceci.

Code :

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

1
2
3
4
 
SELECT limit 333 valeur 
FROM histoVL 
WHERE idprod % 3=0

[blaz]

pas mal comme solution. Mais le problème est que les idprod ne se suivent pas. Leur numérotation est assez aléatoire.
Donc on ne peut utiliser ce champ là.

Par contre, il ya dans la table un champ date qui permet de les ordonner.
Mais les dates peuvent avoir des trous (à cause des WE, des jours fériés etc).

[WOLO Laurent]

Mon cher avec tous les problème de MySql, nous devant proceder en plusieurs étapes.

Code :

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

1
2
3
4
 
1-Créer une table identique ayant les mêmes champs que la table histoVl 
2-Inserer dans cette table, les resultats d'un select sur la table histoVl ordonner par le champs date
3-Utiliser la requête citée plus haut.

J'espère qu'il n'ya pas de raison pour que cela échou.

[Bouboubou]

Tu as dit que tu travaillais avec MySQL 4.0... on m'a dit que dans cette nouvelle version, il a possibilité de faire des procédures stockées... c'est juste? Si c'est le cas, faire un function qui te retourne tes 333 valeurs me semble plus simple que de construire des tables temporaires. Je ne comprends pas bien Wolo Laurent qui te sugère de doubler des données dans une autre talbe => risque d'incohérence, etc.

A+

[Bouboubou]

ou peut-être qu'avec une requête tu peux t'en sortir, je ne sais pas si le modulo existe sous MySQL!?!?

Code :

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

1
2
3
4
SELECT valeur 
FROM histoVL 
WHERE idprod='1458' 
AND indice % 3 = 0;

Je pense que cela devrait jouer, mais je ne peux malheureusement pas tester cela maintenant.

A+

[WOLO Laurent]

Je ne comprends pas bien Wolo Laurent qui te sugère de doubler des données dans une autre talbe => risque d'incohérence, etc.

A+

Ou est ce que tu as vu cela ?

[blaz]

Enfait, la solution avec modulo aurait été parfaite si la numérotation des produtis dans la base se suivait, ce qui n'est pas le cas (ce que je n'ai pas forcément traduit dnas mon exemple).
Pour le cas des procédures stockées effectivement, là aussi ça aurait pu être une bonne idée, mais ces procdédures ne sont disponibles que dans la version 4.1 de mysql, version qui est encore en mode alpha (en debuggage)
Donc, finalement je me suis résolu à porter l'algorythme de "triage" des données au niveau de l'application plutôt qu'au niveau SQL.

Merci pour votre aide.

[blaz]

enfin la solution de la table temporaire est efectivment la seule solution viable pour répondre à ma question, mais dnas la mesure ou il y a un risque qu'il yait plusieurs accès en même temps à la base histoVL (en SELECT) il risque d'y avoir une surdémultiplication de tables temporaires qui vont conduire à l'engorgement de la mémoire du serveur.