Calcul de solde progressif en php mysql
Fermé
ndalaba
Messages postés
2
Date d'inscription
samedi 30 août 2008
Statut
Membre
Dernière intervention
26 juin 2013
-
7 janv. 2011 à 16:00
Reivax962 Messages postés 3671 Date d'inscription jeudi 16 juin 2005 Statut Membre Dernière intervention 11 février 2021 - 16 nov. 2011 à 11:18
Reivax962 Messages postés 3671 Date d'inscription jeudi 16 juin 2005 Statut Membre Dernière intervention 11 février 2021 - 16 nov. 2011 à 11:18
A voir également:
- Calcul de solde progressif en php mysql
- Solde steam 2023 - Guide
- Solde forfait mobile - Guide
- Solde carte fidélité auchan - Guide
- Contour progressif illustrator ✓ - Forum Illustrator
- Solde avenue avis - Forum Vos droits sur internet
1 réponse
Reivax962
Messages postés
3671
Date d'inscription
jeudi 16 juin 2005
Statut
Membre
Dernière intervention
11 février 2021
1 011
7 janv. 2011 à 16:23
7 janv. 2011 à 16:23
Bonjour,
Je vois deux genres de solutions :
1 - une sous requête ;
2 - une variable.
La première nécessite l'existence d'une colonne qui permette d'ordonner les données, mais tu as très certainement une date et une heure qui fera l'affaire.
Voici ce que ça pourrait donner :
1 -
Ça a l'avantage de tenir en une seule instruction, mais l'inconvénient de recalculer la somme à chaque itération.
2 -
C'est a priori plus optimisé en termes de performances et n'utilise pas de sous-requête. Par contre, ça tient sur deux instructions, et surtout je ne suis pas complètement sûr du comportement de la somme s'il y a un ORDER BY qui s'y rajoute (la somme se fait-elle sur les ligne telles qu'elles remontent du table scan, qui vont être triées a posteriori, faussant les résultats, ou se fait-elle après le ORDER BY ?)
Je n'ai pas de MySQL sous la main pour trancher, mais en tous cas ça te donne déjà deux pistes de travail.
Xavier
Je vois deux genres de solutions :
1 - une sous requête ;
2 - une variable.
La première nécessite l'existence d'une colonne qui permette d'ordonner les données, mais tu as très certainement une date et une heure qui fera l'affaire.
Voici ce que ça pourrait donner :
1 -
SELECT
c1.dateHeure,
c1.montant,
(SELECT SUM( montant )
FROM caisse c2
WHERE c2.dateHeure <= c1.dateHeure) AS cumulMontant
FROM caisse c1
ORDER BY c1.dateHeure
Ça a l'avantage de tenir en une seule instruction, mais l'inconvénient de recalculer la somme à chaque itération.
2 -
SET @cumul:=0;
SELECT
c1.dateHeure,
c1.montant,
(@cumul:=@cumul+ (c1.montant)) AS cumulMontant
FROM caisse c1
C'est a priori plus optimisé en termes de performances et n'utilise pas de sous-requête. Par contre, ça tient sur deux instructions, et surtout je ne suis pas complètement sûr du comportement de la somme s'il y a un ORDER BY qui s'y rajoute (la somme se fait-elle sur les ligne telles qu'elles remontent du table scan, qui vont être triées a posteriori, faussant les résultats, ou se fait-elle après le ORDER BY ?)
Je n'ai pas de MySQL sous la main pour trancher, mais en tous cas ça te donne déjà deux pistes de travail.
Xavier
7 janv. 2011 à 16:33
Ce qui me semble être plutôt une bonne nouvelle pour le fonctionnement de ma deuxième solution, qui devient donc celle à privilégier.
Xavier
15 nov. 2011 à 20:38
Je débute en mysql avec Version du serveur: 5.1.41-3ubuntu12.10 (phpmyadmin Version: 3.3.2deb1) et je vois que vos deux formules donnent satisfaction ... jusqu'au moment où les lignes 1 et 2 de la table contiennent le même nombre. Avec la formule 1 (pas de variable) dans ce cas, le cumul commence en ligne 1 avec pour résultat 2 fois le nombre! (je n'ai pas essayé avec la formule 2).
Savez-vous ce qui se passe?
Merci beaucoup.
Modifié par Reivax962 le 16/11/2011 à 11:19
Oui c'est logique...
Il te faudrait un autre critère de tri, qui soit strict.
Par contre, la deuxième méthode donnée plus haut ne devrait pas rencontrer ce problème.
Xavier