historique membres - BDD ou fichierXML

[Hell-AstiK]

Bonjour,
pour mon futur jeu, je souhaite faire un historique des actions de chaque membres.
C'est à dire, comme ceci :
http://www.jeuweb.org/showthread.php?tid=564

Je veut que chaque actions (heure de connexion, achats, dépenses diverse, etc...) de chaque membres soient enregistrés.
Je voudrais ensuite, que chaque actions datant de > x heures soit effacées (48h par exemple).


Mais je me poser la question :
Faire un fichier XML pour chaque membres, avec toutes les actions récentes (x heures) dedans (mieux lisible ?)
ou, enregistrer tout sa dans la BDD dans une table ? (habituel)


Qu'en pensez vous ?

[Sephi-Chan]

Moi je pense que la base de données convient très bien.


Sephi-Chan

[Hell-AstiK]

Moi je pense que la base de données convient très bien.


Sephi-Chan

Merci de participer au débat.

En quoi la BDD conviendrais mieux que des fichiers XML ?

[Sephi-Chan]

La base de données permet de trier facilement les colonnes, de faire des conditions, etc.
Et en fait, c'est aussi parce que je ne vois pas d'avantages particuliers à XML : c'est plus lourd en terme de volume de données, plus lourd à traiter (pour le tri et les conditions, notamment) et plus lourd à écrire (c'est naze d'écrire du XML en PHP).


Sephi-Chan

[php_addict]

oui et puis te toute facon apache sera plus efficasse pour ecrire des donnees sur le disque qu'un script fait maison...

[Sephi-Chan]

oui et puis te toute facon apache sera plus efficasse pour ecrire des donnees sur le disque qu'un script fait maison...

Plus de piles dans le correcteur orthographique ? :p

Plus sérieusement, c'est MySQL qui écrit, pas Apache, et il est effectivement plus performant que PHP à ce petit jeu. C'est plutôt important pour un système si sollicité que celui des logs.


Sephi-Chan

[Roworll]

Pour ma part, j'ai fait le choix du XML et ce pour plusieurs raisons propres au fonctionnement de mon application.

- Les logs n'affichent que les informations concernant le joueur en cours.
- En passant par XML, je créé simplement un fichier par joueur et par jour.
- Je me suis fait une toute petite classe pour générer ces XML, je n'utilise donc pas les classes plus lourdes propres à PHP.
- La suppression des anciens fichier se fait simplement via un CRON chaque nuit.
- Toutes mes données sont affichées via des feuilles XSL. L'organisation et le filtrage des données est donc réalisé sur le poste client. Pas de traitement supplémentaire via BDD ou PHP

L'affichage des pages de logs pour un joueur revient à simplement inclure X fichiers XML en fonction du nombre de jours d'historique à afficher. Pas de requête SQL, pas de trafic supplémentaire généré.

Encore une fois, c'est un système adapté à mes besoins. Son grand avantage est d'utiliser les feuilles XSL pour le rendu ce qui en soit est déjà une exception.
En fonction de ce que tu souhaites faire, il est plus ou moins certain que cela ne te conviendra pas. Si tu dois par exemple parser le XML pour le mettre en forme correctement avant de le renvoyer vers le client, il y a des chances que ce soit plus pénalisant niveau ressources.

Maintenant, une purge de l'historique sur une base de données peut aussi mettre ton serveur SQL à genoux en fonction du volume de données à effacer et des méthodes employées. Dans le cas de logs, mieux vaudra privilégier une série de petites transactions (joueur par joueur ou heure par heure) plutôt qu'une grosse requête qui posera des verrous dans tous les sens pendant un temps plus ou moins long.

[keke]

Contrairement à RoworII, j'ai utilisé un système bien lourd en base de donnée. Au moins 5 tables, des logs croisées (un joueur voit certains types d'action des autres joueurs, mais pas toute, et ce, en fonction de la perception, de la position relative des joueurs), des logs avec 1 ou plusieurs protagonistes (joueur, monstre, batiment...).
Chaque table contient la date d'inscription des logs. Ainsi, en cas de purge, je me fie à cette date.

Le système est lourd en terme d'espace. Chaque déplacement rempli parfois une 30 aine d'enregistrement. Cependant, c'est aussi très rapide, très modulable, très fiable, etc.

kéké

[Hell-AstiK]

Mouarf :good:
On en revient à la ou j'en étais, je trouve des avantages et inconvénients de chaque cotés, donc je ne sait pas vers le quel me tourner.

Pour petit info, ces historiques ne servirons que à moi, il ne seront pas affichés dans le jeux aux membres.

[Sephi-Chan]

Mouarf :good:
On en revient à la ou j'en étais, je trouve des avantages et inconvénients de chaque cotés, donc je ne sait pas vers le quel me tourner.

Pour petit info, ces historiques ne servirons que à moi, il ne seront pas affichés dans le jeux aux membres.

Mon conseil : va au plus simple. Ne perds pas ton temps sur des choix si superficiels : ça n'influera pas sur le reste de ton système (puisque tu créera bien sûr une classe de log !).

La base de données est la solution la plus simple et la plus générique. L'utilisation de XML est ultra spécifique.

D'ailleurs, Roworll, outre le dernier point de ta liste, je ne vois pas ce qui fait que XML est plus adapté :

Pour ma part, j'ai fait le choix du XML et ce pour plusieurs raisons propres au fonctionnement de mon application.

- Les logs n'affichent que les informations concernant le joueur en cours.
- En passant par XML, je créé simplement un fichier par joueur et par jour.
- Je me suis fait une toute petite classe pour générer ces XML, je n'utilise donc pas les classes plus lourdes propres à PHP.
- La suppression des anciens fichier se fait simplement via un CRON chaque nuit.
- Toutes mes données sont affichées via des feuilles XSL. L'organisation et le filtrage des données est donc réalisé sur le poste client. Pas de traitement supplémentaire via BDD ou PHP

• Sauf erreur de ma part, le système utilisé ne fait aucune différence au sujet du premier point.
  
• Tu découpes ton architecture en une multitude de fichiers, ce que tu fais virtuellement avec GROUP BY en SQL.
  
• L'API de log que tu as réalisé peut n'être qu'une interface qui admet plusieurs systèmes de stockage, à la manière de Zend Framework qui propose des API avec une multitude de backends possibles (par exemple pour l'internationalisation, tu peux choisir d'utiliser Gettext, des fichiers CSV, des tableaux PHP, des fichiers INI, etc.)
  
• La suppression de vieilles entrées se fait très bien avec un Cron et une base de données aussi. Supprimer N (ou N est le nombre d'actif dans le jeu * la quantité moyenne d'action journalisées qu'ils effectuent) entrées dans une seule table selon un critère de date sera très rapide. Il n'aura même pas supprimer par lot (batch) tant qu'il n'aura pas une masse importante d'utilisateurs.
  
• Et pour le dernier point, c'est effectivement un bel avantage : le tri côté client. Après, ça peut se faire en utilisant Javascript sur la page d'affichage : ce n'est pas plus compliqué d'utiliser un plugin jQuery (pour faire des tableaux triables/filtrables) que d'écrire du XSL et du XPath.
  

Après, j'ai peut-être loupé quelque chose. Je sais que tu aimes beaucoup XML et XSL, mais as-tu choisi ça par goût de la techno ou par réel intérêt ?


Sephi-Chan