je comprends pas pourquoi t'as des insert Oo ?!?!
d'après moi faut changer ta logique (tu descends aux nombre de requête = au nombre de type de vote si je pars du principe qu'ils ont tous un pas de temps différent), et tu peux même encore faire mieux si tu es prêt à faire un sacrifice supplémentaire sur l'exactitude (là t'a en gros plus qu'une requête par jour)^^
parce que la si je comprends bien le problème; moi j'aurais dans une table joueur avec un champ int (ou plus petit histoire d'optimiser selon combien on peut avoir de vote max; et sinon un simple bool/enum si on peut pas cumuler) pour chaque type de vote en plus du champs int pour le timestamp unix de la date de connexion. Et dans une autre table "maintenance" j'aurais juste les timestamps unix de la date de la dernière maintenance pour chaque type de vote
à partir de la pas sorcier:
- ton temps now.
- une requête lecture pour obtenir le timestamp de la dernière maintenance pour le type de vote A, et si je suis pas faux à calculer le "décalage" (le truc est que tu vas pas être pile poile à la seconde prêt à lancer ta manitenance pile au temps de ton intervalle de pas)
- ensuite t'auras une super requête update qui traverse toute ta table avec un update +1 sur vote A si condition (le truc qui te calcul bien que faut faire la mise à jour)... enfin quoique je me trompe lago correcte c'est peut-être le contraire c'est condition where 1; et tu fais une jolie formule update +floor(le truc qui te fait le calcul genre modulo tes temps/pas de temps).
l'alternative si ta pas envie de te faire chier à faire le calcul pour prendre en compte le décalage du au jour d'inscription; c'est de bêtement distribué pour tout le monde tes votes à date fixe selon tes intervalle de temps. (à la limite t'es gentil avec les nouveaux inscrits et tu fait dans ta table que par défaut la valeur vaut 1 plutot que zéro
comme ça ils pourront pas se plaindre d'avoir à attendre pour le premier vote parce qu'ils ont pas eu de bol et se sont inscrit juste arpès la distrib du vote )
enfin 3e alternative, perso ma préférée car algo qui parait aussi plus simple, si les joueurs peuvent cumuler les votes; c'est bêtement compter le nombre de vote de type A fait (vote_utilisé). A partir de là tu détermine facilement avec la date inscriptions, la date courante et le pas de temps de ton vote le nombre de vote auquel le joueur à droit (vote_du): nombre de vote encore dispo = vote_du - vote_utilisé. (avec ça t'as plus besoin d'opération merdique de maintenance)
d'après moi faut changer ta logique (tu descends aux nombre de requête = au nombre de type de vote si je pars du principe qu'ils ont tous un pas de temps différent), et tu peux même encore faire mieux si tu es prêt à faire un sacrifice supplémentaire sur l'exactitude (là t'a en gros plus qu'une requête par jour)^^
parce que la si je comprends bien le problème; moi j'aurais dans une table joueur avec un champ int (ou plus petit histoire d'optimiser selon combien on peut avoir de vote max; et sinon un simple bool/enum si on peut pas cumuler) pour chaque type de vote en plus du champs int pour le timestamp unix de la date de connexion. Et dans une autre table "maintenance" j'aurais juste les timestamps unix de la date de la dernière maintenance pour chaque type de vote
à partir de la pas sorcier:
- ton temps now.
- une requête lecture pour obtenir le timestamp de la dernière maintenance pour le type de vote A, et si je suis pas faux à calculer le "décalage" (le truc est que tu vas pas être pile poile à la seconde prêt à lancer ta manitenance pile au temps de ton intervalle de pas)
- ensuite t'auras une super requête update qui traverse toute ta table avec un update +1 sur vote A si condition (le truc qui te calcul bien que faut faire la mise à jour)... enfin quoique je me trompe lago correcte c'est peut-être le contraire c'est condition where 1; et tu fais une jolie formule update +floor(le truc qui te fait le calcul genre modulo tes temps/pas de temps).
l'alternative si ta pas envie de te faire chier à faire le calcul pour prendre en compte le décalage du au jour d'inscription; c'est de bêtement distribué pour tout le monde tes votes à date fixe selon tes intervalle de temps. (à la limite t'es gentil avec les nouveaux inscrits et tu fait dans ta table que par défaut la valeur vaut 1 plutot que zéro
comme ça ils pourront pas se plaindre d'avoir à attendre pour le premier vote parce qu'ils ont pas eu de bol et se sont inscrit juste arpès la distrib du vote )enfin 3e alternative, perso ma préférée car algo qui parait aussi plus simple, si les joueurs peuvent cumuler les votes; c'est bêtement compter le nombre de vote de type A fait (vote_utilisé). A partir de là tu détermine facilement avec la date inscriptions, la date courante et le pas de temps de ton vote le nombre de vote auquel le joueur à droit (vote_du): nombre de vote encore dispo = vote_du - vote_utilisé. (avec ça t'as plus besoin d'opération merdique de maintenance)