Gestion Des ressources

[MadMass]

Euuuuh ça dépend ?
Si tes 3 updates se font sur la même requête et qu'elles vont modifier la même ligne de ta table, que ce soit un update ou 4 update ça ne changera rien niveau vitesse.
D'expérience, le plus coûteux avec une base de données c'est la localisation d'une entrée au sein d'une table. Une fois que ton entrée est localisée, que tu changes une ou 4 valeurs sur cette entrée c'est négligeable.

[Xenos]

Attention à l'ordre des updates portant sur plusieurs colonnes (UPDATE ... SET ... = ..., ... = ...) car ils s'exécutent dans l'ordre des colonnes de la requête: UPDATE ... SET x=x+1, y=x+1 fera d'abord x=x+1 et ensuite y=x+1=(x+1)+1

Sinon, tu peux t'esquiver la mise à jour de la date par un trigger (cela évite de l'oublier coté code client et cela évite de lancer une requête de plus du client vers le serveur). Voire, au besoin , si tu as 3 UPDATES portant sur différentes tables, fusionner tout cela en une procédure (et cela ne fera qu'un appel client-serveur qui lancera cette procédure faisant 3 requêtes, jusqu'à ce que tu trouves une meilleure procédure).

[niahoo]

Disons que si un jour tu trouves ça lent tu pourras toujours réorganiser tes données. Mais pour le moment si ça fonctionne, ne t'inquiète pas.

Ensuite tu dois pouvoir facilement mettre à jour tout ça avec une seule requête non ?

[killianr]

Merci beaucoup pour toutes vos réponses,

En effet les 4 modifications se font sur la même ligne ce qui veut dire comme vous l'avez dit que tout ce fait en une requête, je vais aussi me pencher du coter du trigger merci Xenos.

Killian

[Xenos]

Fais gaffe au TRIGGER quand même car je viens de penser que, dans ton cas, tu auras peut-être à ajouter genre 1000 unités de ressources à un joueur (par exemple, parce qu'il décharge des ressources ou pour d'autres raisons). Dans un tel cas, faire un UPDATE pour ajouter les ressources va déclencher le TRIGGER. Donc, ne fais peut-être pas un TRIGGER qui mettrait juste à jour la date du calcul de production à chaque UPDATE de la ligne de BDD.

[killianr]

Salut,
J'ai une dernière petite question.
Prenons par exemple ces valeurs:

- 5 de pierres/minute
- Actualisation par minute

Donc je fait la différence entre 2 timestamp ce qui me donne le nombre de seconde qui c'est écoulé depuis la dernière mise a jour des ressources.
Je divise par 60 pour connaître le nombre de minute écoulé depuis la dernière mise a jour.

Et je multiplie ce nombre de minute par 5.

Le problème est que si je veut un nombre de pierre exacte je suis obligé soit d'arrondir au supérieur soit a l'inférieur.

Le problème c'est que si le joueur actualise avant que la minute ce soit terminé et que j'arrondis a l’inférieur il ne reçoit rien et si j'arrondis au supérieur et qu'il actualise avant que la minute soit terminé il va gagner de la pierre plus rapidement.

Je n'est pas réussi a trouver de compromis le moyen que j'utilise pour le moment c'est de laisser 2 chiffres après la virgule mais cela n'est pas très jolie d'afficher des chiffres après la virgule.

Si vous avez des idées ou si il existe un moyen de n'afficher que le nombre entier mais de continuer de calculer dans la bdd avec les chiffres après la virgule.


Killian

[Xenos]

Ca, c'est donné par niahoo dans un message précédent car cela avait été déjà discuté.

Perso, j'ai deux approches: soit faire des valeurs décimales, et n'arrondir les choses qu'à l'affichage/au select (à l'entier inférieur), ce qui permet d'avoir un backend simple avec des nombres décimaux pour un front simple avec des entiers, soit faire un temps minimum, c'est à dire ne pas utiliser la seconde comme pas de temps, mais le 1/5e de minute (aka arrondir le temps au 1/5e de minute inférieur, ce qui fera des nombres entiers et une date d'actualisation qui sera entre 11 et 0 secondes avant NOW()).

[MadMass]

Oui travailles en décimaux de ton côté, et pour l'affichages du affiches l'arrondi inférieur. De cette façon la production de pierres reste absolument constante.