+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : [Résolu] Des altérnatives à mon système de vote (/showthread.php?tid=3462)
Pages :
1
2
[Résolu] Des altérnatives à mon système de vote - Sephi-Chan - 20-12-2008
Bonjour à tous,
Je viens vous consulter pour chercher des alternatives à l'insertion de données au sein d'une boucle.
Je dispose d'un certain nombre de joueurs qui obtiennent des votes (à distribuer à leur guise) à compter de leur inscription. Ils obtiennent par exemple un vote A tous les 7 jours, un vote B tous les 6 jours, etc. pour environ 5 à 8 types de votes.
Il bouclera donc sur chaque individu et lui donnera les votes nécessaire. Ce qui fait tout de même pas mal d'insertion dans un intervalle de temps plutôt court.
Quel est votre ressenti sur la question ? Peut-t-on sans trop de problème exécuter un petit paquet de INSERT dans un court intervalle (chaque jour, à minuit, par exemple) ?
Si vous avez des suggestions et/ou des alternatives à ce système, je suis preneur.
Sephi-Chan
RE: Des altérnatives à l'insertion de données au sein d'une boucle ? - Ruz - 21-12-2008
euh, dans ce cas là, si c'est des insert dans la meme table, ta boucle n'a qu'a servir à créer la requete, que t'éxécute uniquement si elle dépasse un certain nombre d'insert... (et une fois après ta boucle). Ca va déjà diminuer ton nombre d'insert...
ex: (pas formaté)
$v='';
$req='insert into table (C1, C2) VALUES';
$n=0;
while(blabla)
{
$req.=$v.'('id','vote')';
$n++;
$v=',';
if($n==100)
{
mysql_query($req);
$req='insert into table (C1, C2) VALUES';
$v='';
$n=0;
}
}
if($n>0){mysql_query($req);}
c'est ce que tu demandais???
Si c'est trop lourd => maintenance nocturne... c'est fait pour ca, non?
RE: Des altérnatives à l'insertion de données au sein d'une boucle ? - wild-D - 21-12-2008
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)
RE: Des altérnatives à l'insertion de données au sein d'une boucle ? - Sephi-Chan - 21-12-2008
Les solutions que tu proposes ne sont pas applicables dans mon contexte puisque les votes sont individuels.
- Chaque vote doit avoir sa durée de vie ;
- La date d'utilisation des votes doit être conservé ;
Pour éviter une consommation trop importante de ressource à un moment donné (et puisque je ne souhaite pas que les votes soient attribués au milieu de la nuit), je pense opter pour un contrôle effectué lors des actions du joueur. Ainsi, la gestion des votes est étalée dans le temps.
Sephi-Chan
RE: Des altérnatives à l'insertion de données au sein d'une boucle ? - wild-D - 21-12-2008
va falloir préciser le détail du cas pratique... parce que je comprend pas bien comment fonctionne ton système de vote.
- en gros t'as un vote, tu l'utilise, il a une durée de vie de X jours, et quand arrive le Xe jour tu retrouve ton vote ?
Si c'est ça effectivement mes idées sont à coté de la plaque, mais si c'est pas ça; et que le gain de vote et la durée de vie du vote ne sont concomitants; je vois pas en quoi mes solutions sont HS. (la gestion du vote "utiliséé" et celle du gain de vote n'étant alors pas lié)
RE: Des altérnatives à l'insertion de données au sein d'une boucle ? - Sephi-Chan - 21-12-2008
Les joueurs reçoivent des votes (chacun d'un certain types) à intervalle régulier (cet intervalle vaut la durée de vie spécifique aux votes de ce type).
Les joueurs peuvent voir et utiliser les votes si la date au moment du vote est antérieure à la date d'obtention du vote + la durée de vie du vote (exprimée en jour). Au dela, le vote est considéré comme mort : il n'est plus affiché, plus utilisable et il sera détruit lors d'une purge. En revanche, un vote qui a été attribué reste stocké (on met seulement à jour sa date d'utilisation (jusque là à NULL) et sa cible (la personne à qui on a attribué le vote).
Sephi-Chan
RE: Des altérnatives à l'insertion de données au sein d'une boucle ? - wild-D - 22-12-2008
idée pour les insertions: une autre variante pourrait être de boucler d'abord en écriture dans un fichier; et ensuite un load file.
---
C'est pas que je sois dur à la comprennette quoi que
; mais j'ai toujours de la peine à comprendre l'intérêt de faire tes insert préalable à NULL. Pour l'instant la seule configuration où ça aurait limite un sens c'est si le droit de vote n'était pas accordé à tous les joueurs; parce que sinon ben j'arrive toujours pas à comprendre l'utilité des ces insert initiaux; si tous les joueurs ont accès à tous les type de vote, pour déterminer si un joueur peut voter ou pas t'en a pas besoin (ça règle le problème des insert en masse de manière simple non
). Et si y a des restriction sur les accès au droit de votes, là effectivement c'est autre chose. Mais ça dépendera des règles d'obtention des droits de vote afin de savoir si y a moyen de faire sans ces insert initiaux ou pas.
RE: Des altérnatives à l'insertion de données au sein d'une boucle ? - Sephi-Chan - 22-12-2008
Il n'y a pas d'insertion à NULL !? :o
Voici les colonnes de la table votes :
character_id # Possesseur du vote.
target_id # Cible du vote (initialement à NULL puisque le vote n'est pas attribué).
type_id # Type de vote.
getting_id # Timestamp à l'obtention du vote.
using_id # Timestamp à l'utilisation du vote.
Je ne vois pas quoi dire de plus que ce que j'ai déjà dit… Le joueur a une réserve de votes qu'il doit utiliser ou non dans un intervalle donné.
Et je me pose des questions sur la meilleure façon de gérer l'attribution de ces votes.
Sephi-Chan
RE: Des altérnatives à l'insertion de données au sein d'une boucle ? - wild-D - 22-12-2008
(22-12-2008, 01:34 AM)Sephi-Chan a écrit : Je ne vois pas quoi dire de plus que ce que j'ai déjà dit… Le joueur a une réserve de votes qu'il doit utiliser ou non dans un intervalle donné.
Et je me pose des questions sur la meilleure façon de gérer l'attribution de ces votes.
Et ma réponse actuellement est pourquoi tu te fais chier à gérer cette attribution ? (temps que cette règles d'attribution est identique pour tous les joueurs)
Si j'ai bien compris le système, pour moi une gestion implicite me parait bcp plus simple. (pas besoin d'insert préalable avec une cible à NULL; soit le gars à utilisé son vote dans ce cas ben t'as l'insert complet; et dans le cas contraire, t'as rien -si j'ai capté le système, getting_id, tu peux le retrouvé implicitement au moment du vote, à la limite t'as même pas besoin de le stocker du tout -).
RE: Des altérnatives à l'insertion de données au sein d'une boucle ? - Zamentur - 22-12-2008
Pourquoi n'enregistrerai tu pas dans ta table uniquement les votes utilisés?
Si les votes sont attribué à intervalle régulier, il est possible de déterminer le nombre de vote encore utilisable rien qu'en comptant ceux déjà utilisé et avec une fonction dépendant du temps(genre modulo).
Enfin çà t'éviterais d'avoir à rentrer tous les x temps des données.
D'ailleurs si tu peux peut être même le faire avec une vue MySQL...
Enfin c'est qu'une piste j'ai pas testé, mais ce serais plus efficace!
EDIT: zut me suis fait doublé par wild-D!