+- 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 : Gestion des ressources (/showthread.php?tid=4242)
RE: Gestion des ressources - Sephi-Chan - 07-08-2009
Pouvez-vous donner les avantages de vos solutions à base d'entiers ?
Et les inconvénients des types proposés par MySQL ?
Sephi-Chan, qui sent bien que ces deux listes vont rester vides...
RE: Gestion des ressources - Argorate - 07-08-2009
Quand on raisonne en seconde ou en heure, c'est très lourd de ce tapper des dates et de faire la conversion...
le timestamp étant déja en seconde, en une soustraction c'est fini^^
RE: Gestion des ressources - Sephi-Chan - 07-08-2009
Si ça n'est que ça, je te conseille de regarder du côté de la documentation de MySQL. Tu verras que les fonctions de dates et d'heure gèrent de la fougère, même à l'échelle des heures et des secondes.
http://dev.mysql.com/doc/refman/5.0/fr/date-and-time-functions.html
En plus de la lisibilité ("interval 1 minute", c'est très maintenable), tu auras les performances et surtout : la fiabilité. Et quand je vois tes déconvenues avec le temps sur l'autre sujet, je me dis que c'est pas du luxe. Ton jeu n'en serai que plus stable.
Enfin, j'espère te convaincre des bienfaits d'utiliser les outils à ta disposition (surtout dans un domaine comme le temps) plutôt que de les "éviter quand tu le peux". Ta roue tournera sans doutes moins bien que celle des développeurs de MySQL.
Sephi-Chan
RE: Gestion des ressources - wild-D - 07-08-2009
si on garde le cadre de la gestion de ressources
^^ autant je suis pour utiliser les dates quand c'est le format de traitement (surtout si c'est en interne en bdd); autant j'en suis bcp moins fan quand il s'agit de faire du traitment en php avec des entier/flottant
(pourquoi pas un timestamp en secondes, si c'est le pas de temps/la donnée utilisé pour les calculs dans php; à quoi sert de faire des opération inutile DATEDIFF, DATEFORMAT ou autre modif alors qu'on peut travailler avec le "format utile" directement ).le cas de gestion de ressource avec un timestamp de référence pour "simuler" la production de ressources stocké en INT plutot que le format de date mysql, c'est justement le cas "exception" qui confirme la règle
(je sais pas mais moi je récup le time de réf, et la valeur en stock, que je balance en session histoire de simuler à l'affichage l'évolution des stock sans requête inutile; t'as quoi de mieux à proposer ? désolé moi je stock le time en bdd pour le stocker en scurité; non pour avoir une date)
RE: Gestion des ressources - Findel - 07-08-2009
Je suis également un adepte du timestamp (donc stockage en int) au lieu des dates. Seulement pour la raison que manipuler un entier c'est plus simple que d'en manipuler 3 (jour, mois, an) voir 5 ou 6 (heure, minute et éventuellement secondes).
Avec le format date, on est toujours à se demander où est le jour et le mois, avec ces fichues différences selon la langue d'install de l'OS ou du SGBD. Parfois même une extraction d'une base pour la remonter sur une autre va "inverser" mois/jour dans toutes les dates, l'horreur.
Ensuite, j'ai eu pour ma part d'énormes soucis à cause des fuseaux horaires, qui poussent à faire des conversions vers un fuseau de référence, qui fait qu'on se demande toujours si l'heure est au format local ou GMT ou autre... Et alors quand arrive les changements d'heures d'été/hivers alors là, on sait plus où on en est.
Avec les fonctions d'affichage/calcul de date côté PHP ou MySQL, ça revient un peu au même d'utiliser un format de stockage date ou entier. A ce que j'ai pu en constater, jamais vu de différence notable entre le travail pour utiliser l'un et le travail pour utiliser l'autre.
Pour moi le timestamp a deux défauts : d'une part c'est pas lisible dans les résultats quand tu fais tes requetes manuelles dans la base (mais franchement vous en faites souvent des requetes directes ? si oui, vous pensez pas que ça vaudrait le coup d'automatiser un peu ?).
D'autre part, il faut faire attention aux additions/soustractions avec les décalages horaires d'été et hivers, donc bien les traiter comme timestamp et pas comme entier lors d'addition/soustraction.