Bonjour,
 
J'ai une table qui stocke des mesures réalisées par un équipement.
La table contient un id, une date et une donnée.
 
Je souhaiterai afficher ces données dans une interface, avec des cumuls par jour / semaine / mois / année, avec un "+" pour dérouler les infos.
 
Je me demande si le plus efficace est de faire :  
 
1) 5 requêtes différentes (total annuel, total mensuel, total hebdo, total quotidien, détail), que j'appelerais au clic sur le "+"
2) 1 requête qui renverrait tous les résultats bien organisés (d'après ce que j'ai vu, le group by avec rollup permettrait ce genre de manipulation)
3) 1 requête qui renverrait tous les résultats sans mise en forme, et pour laquelle je laisserai le code client faire les opérations de somme par année / mois etc.
 
L'option 1 me plait moyennement parce que ça multiplie les appels, mais d'un autre côté ça limite le volume de données échangées
L'option 2 me plait moyennement aussi parce que j'ai toujours entendu et répété que ce n'était pas au SGBD de mettre en forme les données
L'option 3 me plait moyennement en raison du risque de temps de traitement à chaque clic sur l'icône de détail  
 
Du coup, comme je n'ai pas trop d'idée ni de préférence, j'aimerais vos retours.
 
Pour info, la base est mysql, le service qui appelle la base est en php (ça se transformera peut être en node mais pour le moment j'ai commencé avec php), et le code client est en js.
 
Merci,

A part s'il s'agit d'une énorme quantité de donnée et d'un grand nombre d'accès, je penses qu'on est sans doute dans de l'over-optimisation...
 
Faire au plus simple et au plus maintenable (pour toi ou le prochain à devoir modifier ton programme) sera souvent plus utile.
Récupérer toutes les données via le SGBD, faire tes totaux dans des variables bien nommé puis les afficher dans ton html, et enfin gérer l'affichage ou non des lignes via JS me semble "le plus simple" à faire, relire et comprendre...
 
Tu peux aller plus loin dans ton raisonnement et avoir 2 traitements distinct :
 - Juste les GROUP BY fait par le SGBD (qui sera sans doute le plus performant devant PHP et JS) et affiché en dur via PHP
 - le détail requis importé via une requête AJAX si et seulement si on clique sur le plus
Si plus de 50% du temps l'utilisateur se contente du total, ce sera le plus efficace AMHA...
 
NB: Si tu as des problèmes de nombreux accès concurrent ou que ton serveur n'est pas super dimensionné, ça peut être une solution de déporter tous les calculs au niveau du client, dans ce cas tu peux générer des Json avec toutes tes infos et laisser le navigateur s'occuper de l'affichage...

Y'a aussi l'option SGBD avec GROUP BY qui fait les consolidations et PHP qui fait la mise en forme et le client qui ne fait qu'afficher le résultat. Ca limite les volumes de données échangées. Parce que si tu envoies les données par jour sur une période d'1 an et que c'est le client qui consolide et fait la mise en forme, ça va piquer
 
Je pense qu'à ce stade, il faut faire au plus simple : SGBD et PHP font le boulot. Ajax peut juste commander la demande des données et récupérer les données à afficher.
 
Si les requêtes prenaient du temps, une possibilité d'optimisation est de mieux configurer certains paramètres du SGBD (taille du cache par ex).

Ok, en effet, pour le moment c'est peut-être de l'optimisation inutile, mais je n'aime pas trop réécrire quelque chose qui aurait pu être bien pensé dès le début.
Je n'ai pas beaucoup d'accès, pas beaucoup de données, mais conceptuellement je préfère partir sur quelque chose de propre.
 
Du coup pour le moment j'ai cette requête :  
 

 
qui me sort les bonnes infos classées comme je veux, plus qu'à indiquer à JS de masquer / afficher les éléments qui m'intéressent.