[Conception] Historique

[Argorate]

Bonjour à vous,

Je voulais vous demander votre avis sur la conception de l'historique des actions.
C'est à dire stocker qui fait quoi sur qui et a quel moment, ainsi que le résultat de l'action.

Mon problème est pour le stockage en BDD de toutes ces informations.

Admettons qu'on est:

JoueurAgit
JoueurSubit
Date
ResultatAction

Et après comment géré les différentes valeurs à stocker en fonction des actions?

Par exemple pour une attaque il faudrait stocker le chiffre des dégâts infligé, mais pour un vol il faudrait stocker quel objet(s) qui ont était volé. Bref le nombre d'informations - et même le type - à stocker diffère en fonction des actions.

Donc comment gérez-vous ça?

Une solution pourait de faire un champ "data" et de prendre une convention en concatenant les données (séparer par un point virgule par exemple) dans l'ordre qu'on choisira et ceux pour chaque action. Mais n'y a t-il pas mieux?

[Sephi-Chan]

Sois j'utiliserai de l'héritage de table (si j'ai peu de chiffres à stocker), soit je stockerai les chiffres dans des hash (que tu dois mieux connaître sous le nom de tableaux associatifs) sérialisés en JSON.

C'est quand même mieux d'utiliser ce qui existe que de réinventer la sérialisation avec ton histoire de datas… Non ?

Le tout te permettra d'écrire des chaînes comme :

{attacker['name']} a attaqué {target['name']} et lui a infligé {attacker['attack']['damages']} points de dégâts.

Et de substituer par les éléments de ton tableau sérialisé (que tu déserialise avec json_decode) qui aurait (en JSON) cette forme là :

{

  attacker: {

    name: "Sephi-Chan",

    attack: {

      damages: 17

    }

  },

  target: {

    name: "Argorate"

  }

}

Sephi-Chan

[Argorate]

tu as des exemples a me donner pour que se soit plus concret pour moi?

[Sephi-Chan]

Oui, c'est édité !

[Argorate]

Mon histoire de data ce n'est rien de plus que la sérialisation effectivement, donc tu utilises le meme procedé sauf que tu veux me faire passé par du JSON? Quel interet? un split et c'est terminer non?

[Sephi-Chan]

Oui mais ton split c'est naze, ça peut pas stocker des tableaux, par exemple.
Alors que JSON c'est déjà tout fait et comme c'est natif, ça trace.

Retourne la question : quel est l'intérêt d'utiliser split quand JSON est mieux foutu, déjà codé et plus rapide que ce que tout ce que tu pourras faire.

Tu te fais ton tableau en PHP :

$parameters = array(

  'attacker' => array(

    'name' => 'Sephi-Chan',

    'attack' => array(

      'damages' => 17

    )

  ),

  'target' => array(

    'name' => 'Argorate'

  )

);

$parameters_as_json = json_encode($parameters); // Prêt à être stocké dans la table !

Sephi-Chan

[Argorate]

Ok, donc effectivement j'étais pas partie du tout sur la meme chose, pour moi tu me parlais de JS, donc ça me plait bien comme methode

thx.

[niahoo]

+1 pour le JSON.

ça m'a fait penser à la fonction de serialisation des objets native de PHP. C'est moins compact que le JSON en base, et plus long à parser peut-être, mais je me dis que ça pourrait être plus facile à utiliser de base, et donc permettre de dev es fonctionnalités plus rapidement.

Qu'en pensez-vous ?

[Lyososs]

J'ai une question Est-ce que ton historique servira à terme ? Du moins est-ce que le joueur aura accès à cet historique ou est-ce qu'il n'aura qu'un intérêt au niveau des admin pour vérifier une incohérence ou un problème soulevé par un joueur ?

[Sephi-Chan]

+1 pour le JSON.

ça m'a fait penser à la fonction de serialisation des objets native de PHP. C'est moins compact que le JSON en base, et plus long à parser peut-être, mais je me dis que ça pourrait être plus facile à utiliser de base, et donc permettre de dev es fonctionnalités plus rapidement.

Qu'en pensez-vous ?

D'après une discussion sur Stack Overflow, json_encode() est beaucoup plus performant que serialize(), en plus de gérer l'UTF-8.


Sephi-Chan