01-03-2011, 07:16 PM
à mon sens la récursion est "simple", via un tableau à trier.
les événements ne sont finalement pas liés, ils arrivent dans l'ordre (temps)
prenons un exemple. En base :
A est en 10,13
B est en 15,10
#1,A se déplace vers 15,10 départ 10h00, arrivée 11h30
#2,A attaque B départ 11h30, arrivée 11h30
#3,B se déplace vers 12,13 départ 12h00, arrivée 14h00
#x l'id de l'événement
maintenant le script se lance à 15h00, on doit donc résoudre toutes les actions :
phase 1 récupération de la bdd (avec un order by à trouver entre début et fin que j'ai du mal à bien préciser)
t[0] =#1,A se déplace vers 15,10 départ 10h00, arrivée 11h30
t[1] =#2,A attaque B départ 11h30, arrivée 11h30
t[2] =#3,B se déplace vers 12,13 départ 12h00, arrivée 14h00
....
phase 2 on résout les actions dont l'arrivée est avant 15h00 (fonction récursive avec comme paramètre le tableau t)
boucle de t[0] à t[count(t)] :
on résout t[0], ok tout va bien :
+ mise à jour de la position de A en BDD
+ suppression de la ligne #1 en BDD (éventuellement via un tableau pour pouvoir faire à la fin un delete where id in (#1, #x, ...)-+
on résout t[1], là ça se corse un peu, algorithme de résolution, supposons que l'issue soit A écrase B qui fuit au hasard (on dira en 15,16) :
+ mise à jour de A en BDD (trésor, perte, ? ...)
+ suppression de la ligne #2 en BDD
+ parcours de t (de 2 à count() ), suppression de tous les événements concernant B (dans l'exemple unset(t[2])
+ suppression de la ligne #3 en BDD (car abandonné suite à l'événement)
+ création de t[n+1]=#NULL, B se déplace vers 15,16 départ 11h30, arrivée 15h30
+ tri du tableau sur le même algo que le order by de la phase 1
le fait qu'on ait supprimé et ajouté des lignes imposent de stopper la boucle
du coup on rappelle la fonction récursive avec comme paramètre le nouveau table t (déjà trié),
et on recommence, jusqu'à ne plus avoir d'événement finissant AVANT sysdate
phase 3 maj BDD
+ on insert toutes les lignes de t encore présente qui n'ont pas d'id (#NULL pour la fuite de B en 15,16 dans l'exemple)
+ éventuellement si on a bufferisé le delete, c'est le moment de l'appliquer pour toutes les actions résolues (évidement avec id, celles sans id n'ont pas besoin d'être persistées : elles ont été créés et immédiatement résolues par le script)
voilà, je ne sais pas si je suis clair, y a peut être une faille
les événements ne sont finalement pas liés, ils arrivent dans l'ordre (temps)
prenons un exemple. En base :
A est en 10,13
B est en 15,10
#1,A se déplace vers 15,10 départ 10h00, arrivée 11h30
#2,A attaque B départ 11h30, arrivée 11h30
#3,B se déplace vers 12,13 départ 12h00, arrivée 14h00
#x l'id de l'événement
maintenant le script se lance à 15h00, on doit donc résoudre toutes les actions :
phase 1 récupération de la bdd (avec un order by à trouver entre début et fin que j'ai du mal à bien préciser)
t[0] =#1,A se déplace vers 15,10 départ 10h00, arrivée 11h30
t[1] =#2,A attaque B départ 11h30, arrivée 11h30
t[2] =#3,B se déplace vers 12,13 départ 12h00, arrivée 14h00
....
phase 2 on résout les actions dont l'arrivée est avant 15h00 (fonction récursive avec comme paramètre le tableau t)
boucle de t[0] à t[count(t)] :
on résout t[0], ok tout va bien :
+ mise à jour de la position de A en BDD
+ suppression de la ligne #1 en BDD (éventuellement via un tableau pour pouvoir faire à la fin un delete where id in (#1, #x, ...)-+
on résout t[1], là ça se corse un peu, algorithme de résolution, supposons que l'issue soit A écrase B qui fuit au hasard (on dira en 15,16) :
+ mise à jour de A en BDD (trésor, perte, ? ...)
+ suppression de la ligne #2 en BDD
+ parcours de t (de 2 à count() ), suppression de tous les événements concernant B (dans l'exemple unset(t[2])
+ suppression de la ligne #3 en BDD (car abandonné suite à l'événement)
+ création de t[n+1]=#NULL, B se déplace vers 15,16 départ 11h30, arrivée 15h30
+ tri du tableau sur le même algo que le order by de la phase 1
le fait qu'on ait supprimé et ajouté des lignes imposent de stopper la boucle
du coup on rappelle la fonction récursive avec comme paramètre le nouveau table t (déjà trié),
et on recommence, jusqu'à ne plus avoir d'événement finissant AVANT sysdate
phase 3 maj BDD
+ on insert toutes les lignes de t encore présente qui n'ont pas d'id (#NULL pour la fuite de B en 15,16 dans l'exemple)
+ éventuellement si on a bufferisé le delete, c'est le moment de l'appliquer pour toutes les actions résolues (évidement avec id, celles sans id n'ont pas besoin d'être persistées : elles ont été créés et immédiatement résolues par le script)
voilà, je ne sais pas si je suis clair, y a peut être une faille