J'ai un pb pour écrire la ou les bonnes requêtes SQL (pour MySQl 3.23.x, donc pas de sous-requêtes ) me permettant de calculer le bon nombre de demandes clientes résiduelles (celles encore ouvertes).
 
Une demande cliente passe par un premier statut : "Soumise"
Ensuite, y'a forcément "Prise en compte", "En analyse".
Après on a le choix entre des statuts "Annulée", "En cours", "Traitée"..., revenir à "En analyse"...et boucler sur les autres statuts cité précédemment.
Et à la fin, on passe forcemément par le statut "Clos côté support" (fermeture de la demande par la hotline).
Enfin, si le client est d'accord, il clôture lui aussi via "Clos côté émetteur" (mais ça lui arrive souvent d'oublier) . Par contre, s'il n'est pas d'accord avec la réponse donnée, il peut réouvrir la demande : celle-ci revient alors à "Prise en compte" et c'est reparti pour un nouveau cycle.
 
Je précise que chaque changement de statut est daté (date et heure).
 
Pour calculer les demandes résiduelles en fin de chaque période (ça peut être les jours, les semaines, les mois ou les années), je compte le nb de demandes "Soumises" et "clos côté support" sur chaque période et je calcule la différence de manière incrémentale avec le nb de résiduelles de la période précédente.
ex : On imagine que mes demandes dans la bases commencent à partir de janvier 2005 (aucunes demandes soumises avant cette date).
Le nb de demandes résiduelles du mois de janvier est donc :  
RésidJan = Soumises en Jan - Clos support en Jan
 
Le nb de résiduelles de Février :  
RésidFev = RésidJan + Soumises en Fév - Clos support en Fév
 
Le nb de résiduelles de Mars :
RésidMars = RésidFév + Soumises en Mars - Clos support en Mars
etc.
 
Par ailleurs, une demande qui aurait 2 fois le statut "Soumise" ou "Clos côté support" sur la même période (ici le mois) n'est comptée qu'une fois
 
Mon pb survient quand j'ai des demandes qui sont cloturées durant un mois donné et réouvertes un autre mois puis clôturées à nouveau (durant le mois de réouverture ou un autre mois, peut importe là). De ce fait, la réouverture n'est pas compté comme une demande encore ouverte et au moment de la nouvelle clôture, je me retrouve faux d'une demande résiduelle puisqu'avec ma méthode de calcul, je compte 2 fois la clôture de la demande ...
 
Donc, est-ce-que l'un d'entre vous aurait une bonne méthode pour claculer les demandes résiduelles sachant que compter les demandes qui se trouvent dans un statut compris entre "Prise en compte" et celui situé avant "Clos côté support" ne marche pas dans la mesure où la périodicité de mise à jour des statuts d'une demande est plus longue que le mois (oui, une demande peut ne pas évoluer pendant plus d'1 mois )...
 
Par avance, merci de votre aide. De mon côté, je regarde si c'est pas trop dure de calculer le nb de demandes réouvertes par période...

pas très probant mon truc des demandes réouvertes.
 
En +, y'a le pb qu'une demande peut, après réouvertures, passer plusieurs fois dans le statut "prise en compte" si l'utilisateur a ajouté un commentaire...

Pas simple ton histoire ?
Et si tu fais :  
RésidFev = RésidJan + Soumises en Fév + Réouvertes en Fév - Clos support en Fév    
 
Ainsi, une demande pourrait être comptée plusieurs fois comme clôturée, mais aussi plusieurs fois comme (soumise ou réouverte) ?
 
Ou alors, faire le calcul sans tenir compte du rédiduel précédent
RésidFev = (Nombre d'ouverture <= fév) - (Nombre de Fermetures <= Fév)
 
Ce qui reste à faire à un instant T, c'est tout ce qui est arrivé (nouveau ou réouvert) avant T moins tout ce qui a été fermé avant T

 
Merci de ta proposition
La première : j'ai testé, ça marche pas en pratique car, pour l'instant, j'ai du mal à détecter la réouverture de manière unique pour une demande, comprendre qu'une réouverture = passage de "clos côté support" à "prise en compte", mais comme le cycle de vie est paramétrable, je peux pas coder en dur la détection de passage d'un ID de statut à un autre, donc je regarde si y a des ordres de statuts (1 à n) < à d'autres pour des ID d'entrées dans l'historique >. En effet, à chaque statut est associé un ordre pour savoir sa position dans le cycle de vie (ça permet de créer les statuts dans l'ordre que l'on veut, après, on les classe via leur n° d'ordre). Bon, tout ça pour dire que des fois, lors d'une réouverture, j'ai 2 statuts "prise en compte" qui se suivent sur des mois différents, ce qui fait que je vais compter 2 fois la réouverture de la demande
 
La 2ième : j'ai peur que je ne puisse écrire ce système de comptage avec 1 ou 2 requêtes SQL
 
Piste que je vais tester : exclure du comptage des clôtures les demandes réouvertes et les rajouter ensuite aux demandes clôturées en fonction des dates de clôtures des demandes réouvertes. Ca fait 2 requêtes SQL + un traitement en php sur les résultats...

Il est surement là, le problème. Comment compter quelque chose si tu n'arrives pas à identifier précisément cette chose ?  
Je pense que la priorité, c'est de définir exactement comment une demande passe d'un état à l'autre

 
c'est bien défini, mais c'est l'écriture de la requête qui n'est pas facile et qui pose problème ... C'est pour ça que j'essaye de trouver une méthode de comptage valide et qui ne nécessite pas 36 requêtes sql compliquées

Voici un ex d'historique d'une demande réouverte :
 

 
Si qq'un pouvait m'écrire la requête SQL pour Mysql qui permet de détecter le nb de demandes réouvertes par mois d'ouverture, ce serait sympa. Voilà ce que j'ai fait, moi :  

 
Donc, si qq'un peut améliorer ma requête pour que je ne compte plus les statuts 2, 2, 2, 3, 5, 8 qui suivent la première clôture support, je l'en remercierais

J'ai essayé une autre méthode :  
nb de soumises dans le mois - nb de clôtures dans le mois sans compter les demande réouvertes - nb de clôtures dans le mois des demandes réouvertes.
 
Ben ça marche pas Je commence à être à cours d'idées car je vois pas d'où vient mon pb...

Ca me paraît pas gagné ton truc.
 
Vais tenter une tambouille dans mon coin, mais sans sous-requête, je pense que ça va être tout bonnement impossible à maintenir...

C'est quoi le "AowID" ? C'est le numéro de demande ?
 
Alors pourquoi on ouvre deux-fois la même ?

Je pense que déjà, là, y'a un truc qui cloche. Parceque là, on ne peux pas savoir s'il n'y a qu'une ouverture ou une ouverture puis une réouverture.
 
Ensuite, à la réouverture, on passe à 2 plutôt que 1 (soit). Et idem, on a plusieurs fois le status 2.
 
Là, clairement, y'a un souci je pense.

Le AowID, c'est l'ID d'une demande.
 
Le fait qu'il y ait 2 fois le statut 1 "soumise" ne signifie pas qu'il y a 2 soumission pour la même demande. J'ai viré certains champs (dont le commentaire). Le premier 1 indique la création de la demande, le 2ième 1 contient un commentaire de la part de celui qui affecte la demande à un responsable. Quand le responsable affecté ouvre la demande, elle passe au statut 2. Il peut alors tracer dans l'historique un commentaire, d'où un éventuel 2ième statut 2... Quand y'a une réouverture, on ne repasse pas par le statut 1 mais par le statut 2. Là encore, le resposnable peut tracer un commentaire.
En fait une soumission ou une réouverture est détectée par le passage d'un statut à un autre : soumission -> aucun statut à statut 1, réouverture -> statut 10 à statut 2.
 
Voilà. J'ai été plus clair, là?

ps: au fait, merci de ton aide

ok, donc il faut prendre les aowid = 1 et 2 où commentaire= NULL c'est bien ça ? c'est une règle respectée à coup sûr ou non ?

en fait,il faut pouvoir isoler les lignes où on fait réellement l'action d'ouvrir ou réouvrir.

 
Pour la soumission, effectivement, le commentaire est à NULL. Pour la réouverture par contre, c'est mois sûr. En pratique, y'a rarement un commentaire mais ça peut arriver...

Ben faut une ligne à NULL, ou un flag quelque part qui permette d'isoler la ligne, sinon on ne peux pas exploiter les données...

 
Ben si, en détectant un front (passage d'un statut à une autre). Réouverture = passage de 10 à 2. Si après on a un autre 2, le front est 2 -> 2, c'est donc pas une réouverture.

ouais mais là, en une passe, franchement, je la sens pas du tout (mais alors pas du tout )

 
alors en 2 requêtes peut-être?

ben... c'est surtout que tu vas devoir passer par une boucle, c'est ça que je crainds...
 
vais quand même faire un ou deux tests avant, mais à mon avis c'est sans espoir

a mon avis, tu devrais surtout te concertrer sur une modif de l'appli pour séparrer les "fronts" comme tu dis, plutôt que devoir le faire en interprétant plusieurs lignes. C'est là que ça coince

Bon, je viens de regarder en vitesse, et je trouve une solution passant par une table temporaire.
 
C'est bien ça que tu veux ? :
 
"la liste de toutes les demandes encore ouvertes"
 
Si c'est le cas, moyennant petites modifications, ce lot de requête fonctionne et évite de faire une boucle.
 

 
Je vais être chiant mais bon    
Ta requête, ça donne les demandes actuellement ouvertes... C'est exactement ce genre de requête que j'ai fait pour mon moteur de recherche pour connaître le statut courant d'une demande... Pour rappelle, il me fait les demandes qui étaient ouvertes ou fermées pour chaque mois. A la limite, on pourrait lancer ces 2 requêtes sur chaque mois en limitant la de l'historique de chaque demande, mais ça va être long comme traitement ...

et puis modiffier l'appli, vu qu'il y a 6000 demandes (plus de 45000 entrées dans la table des historiques des demandes), ça va pas être possible
 
Je crois que je vais laisser comme c'est. J'ai un petit différent (8 sur 110)...

Bon, là je rentre chez moi, je verrai ça demain.
 
A mon avis, c'est tout bête de faire cette requête pour chaque mois.
 
Sinon, modifier l'appli, si, tu peux le faire. Au pire, durant les premiers mois, à cause de l'historique qui n'a pas été mis à jour, tu ne pourras pas utiliser les nouvelles données, mais au bout de mettons 6 mois, je doute que ce soit très intéressant de retrouver les demandes ouvertes depuis une aussi longue période, donc tu pourras activer la nouvelle requête qui marche mieu

Ceci dit, finalement, je ne sais pas si c'est très utile, donc laisse tomber

 
en tout cas, merci pour ton aide