Crontab

[niahoo]

Plus simplement, ton cron est lancé toutes les 2 minutes et ajoute des points d'action à tous les joueurs indscrits, sans chercher à savoir à quelle heure ils se sont inscrits.

Et si tu veux que personne ne soit lésé, lors de l'inscription tu files en cadeau un paquet de points de départ.

[Sôbi]

Plus simplement, ton cron est lancé toutes les 2 minutes et ajoute des points d'action à tous les joueurs indscrits, sans chercher à savoir à quelle heure ils se sont inscrits.

Oué, je vois ce que tu veux dire ...
Me faut une date de référence histoire d'avoir tout de même côté IHM un temps restant du PA à venir...

Pas mal les idées

Et si tu veux que personne ne soit lésé, lors de l'inscription tu files en cadeau un paquet de points de départ.

C'est ce que je pensais faire çà par contre

[Xenos]

Mouais, je trouve que cela revient encore à faire un cron quotidien qui incrémente la colonne "age" de la table "joueurs" à partir de leur date d'anniversaire. Les colonnes virtuelles (MySQL 5.7) et les vues (si pas 5.7) sont faites pour cela.
Je serai curieux de voir un benchmark des deux méthodes.

[Sôbi]

Vu q'il y a un débat la dessus, je serais aussi également intéresser pour le coup !
( Si un jour une personne le fait :p )

[niahoo]

Comment tu ferais avec ta vue ?

[Xenos]

CREATE ALGORITHM = UNDEFINED VIEW `joueur` AS

 SELECT joueur.id,

 joueur.datePoints AS oldDate, joueur.points as oldPoints,

(NOW() - joueur.datePoints)/60*2 as newPoints, NOW() as newDate

 FROM joueur ;

A voir après s'il vaut mieux une TEMPTABLE ou un MERGE.

L'alternative, c'est de passer par une procédure (CALL... au lieu de SELECT...) qui met à jour les points et fais ensuite un simple SELECT.

Sinon, il y a aussi les colonnes virtuelles du 5.7, mais je n'ai pas encore eu l'occasion de m'en servir (donc je n'ai pas la syntaxe en tête)

[Sôbi]

Désolé de paraître un peu stupide, je n'ai pu lire que très rapidement quelques docs sur les vues.
Mais je vois mal à quel moment il y a une mise à jour ? :S

Et finalement, cette vue est appelée quand ? Tout le temps par MySQL ?

* s'arrache les cheveux, est complètement perdu *

[Xenos]

Le but d'une vue n'est pas de mettre à jour les données, mais d'avoir une "table virtuelle" (qu'on appelle une vue) ayant une colonne avec le nombre de points du joueur à la date d'exécution de la query. C'est une donnée virtuelle, calculée à la volée.

La mise à jour se fera quand tu auras besoin d'enregistrer une modification des points du joueur. Par exemple, le joueur fait une action coutant des points: tu vas mettre à jour sa quantité de points et la date de calcul en utilisant la quantité de points générée par la vue (moins les points que l'action a couté).

[Sôbi]

Donc, dit moi si je me trompe,

Mais j'aurais une vue de ce genre là :

CREATE ALGORITHM = UNDEFINED VIEW `joueur` AS

 SELECT joueur.id,

 joueur.datePoints AS oldDate, joueur.points as oldPoints,

(NOW() - joueur.datePoints)/60*2 as newPoints, NOW() as newDate

 FROM joueur ;

Puis par exemple, le joueur se déplace j'aurais une query comme celle ci :

mysql_query("UPDATE `joueur` SET `newPoints`= newPoints - 1 WHERE joueur.id =1");

c'est ça ?

[Xenos]

newPoints te donne les points à l'instant de la query, donc ce n'est pas la donnée à mettre à jour (même s'il se peut que MySQL sache "rétro-pédaler" et convertir ce UPDATE en un UPDATE de la table sous-jascente, mais je ne parierai pas trop dessus, surtout que la date n'a pas été mise à jour elle).

UPDATE `joueur` SET `oldPoints`=`newPoints` - 1, `datePoints`=NOW() WHERE joueur.id =1

C'est là où je doute de la dénomination "oldPoints" (mieux vaudrait dire "pointsADateT" et remplacer datePoints par "dateT")

D'ailleurs, la mise à jour du datePoints pourrait peut-être même se faire en TRIGGER (à voir). Dans l'idée, le TRIGGER se déclanche quand le champ "pointsADateT" est mise à jour, et ce trigger va mettre la date courante (NOW()) dans le champ "dateT".

---

Voilà le détail du système dans un article dédié