Bonjour à tous !

Je suis en ce moment sur un projet sous Laravel pour me faire la main avec ce framework, et je suis en train de développer un site qui gère un peu de tout sur l'univers des jeux vidéos (système de tournoi, match éliminatoire, poules, brackets etc...) et je suis en train d'intégrer l'API de steam. Je voudrais, tout comme plein de site montrer les statistiques d'un joueur donné (par rapport à sont steam ID) sur différents jeux que je propose. Aujourd'hui CSGO et Rust.

Exemple des statistiques disponibles pour CSGO : https://steamdb.info/app/730/stats/
Au début ce sont les achievements et un peu plus bas les stats disponibles soit une centaine de tête.

Je voudrais avec ça créer un historique pour permettre aux joueurs de suivre leurs progressions à travers différentes statistiques.
Mais je coince au moment du choix du stockage de ces données.

Est-ce une bonne idée de créer :
Première solution : Une table "stats" avec autant de colonne que de statistiques proposées, et ainsi ajouter les valeurs associées à chaque colonne et insérer une colonne date pour l'historique ?
Deuxième solution : Ou (ce que j'avais fais sous symfony) 3 tables : stats / user / user_stats. Où stats à 3 colonnes, l'id / la stats / le libellé. User, bah les utilisateurs ;) et la dernière user_stats qui permet de faire la liaison entre le user et la stats et ainsi j'insère la valeur dans cette table ainsi qu'une date pour permettre de gérer un historique.

Je me dis que faire une centaine de colonne me parrait énorme et sûrement pas optimisé mais à contrario faire le système de liaison. En sachant que l'on possède 194 stats. Ce qui veux qu'avec 500 joueurs, j'ai déjà 97 000 lignes en sachant qu'à partir de là, je n'ai pas l'historique. Avec l'historique j'aurais au moins le double mais pour seulement 500 joueurs...

Dernière solution, je pensais à un stockage en JSON, mais jusqu'à aujourd'hui, je n'ai jamais utilisé le json en stockage de donnée.

Avez-vous des avis à me donnée, ou peut-être des retour d'expérience ?

Merci d'avance.

Cordialement,

3 réponses


Tchoupi
Auteur

Personne aurait une idée ?

alors moi je te dirai solution 3 :D

tu peux très bien te faire une table stats globale (solution 1) qui va stocker toute les infos remonté par steam (ta table de 200 colonnes), et tu te fait un petit script qui tourne la nuit et qui te compile des infos importantes dans une ou 2 tables (heure / heure et/ou jour / jour). car tout n'est pas important dans ce qui est remonté par steam. le nombre totale de kill... on s'en fiche un peu de la progression. a part une droite qui monte... ca va pas vraiment fluctuer. nb_kill / jour par exemple ca, ca peut etre important. ratio de victoire, ratio de précision ? etc...

mysql va beaucoup plus vite pour lire horizontallement que verticalement

ce que tu veux faire s'appel du Entity Attribute Value Model et c'est moche... (en Bdd relationnel j'entend)

EAV models have a host of problems.

Firstly, the massive amount of data is, in itself, essentially unmanageable.

Secondly, there is no possible way to define the necessary constraints -- any potential check constraints will have to include extensive hard-coding for appropriate attribute names. Since a single column holds all possible values, the datatype is usually VARCHAR(n).

Thirdly, don't even think about having any useful foreign keys.

Finally, there is the complexity and awkwardness of queries. Some folks consider it a benefit to be able to jam a variety of data into a single table when necessary -- they call it "scalable". In reality, since EAV mixes up data with metadata, it is lot more difficult to manipulate data even for simple requirements.

The solution to the EAV nightmare is simple: Analyze and research the users' needs and identify the data requirements up-front. A relational database maintains the integrity and consistency of data. It is virtually impossible to make a case for designing such a database without well-defined requirements. Period.
Tchoupi
Auteur

Salut,

Ahah évidemment la solution 3 :p celle que je connais pas du tout :'(
Bon je vais me pencher là dessus si j'ai vraiment pas le choix alors...

Par contre concernant le EAV models, je comprends pas tout .... Pour moi le EAV models est le faîtes de créer une table avec une seule colonne et d'y insérer toutes les valeurs que je récupère, or ce n'est pas mon cas, j'aurais plutôt 200 colonnes.

Je vais quand même regarder du côté du stockage en JSON, mais est-ce que le faîte de stocker 200 colonnes (en soit ce n'est que des nombres) multiplié par des miliers de lignes peut ralentir le serveur et donc le traitement de données ?

Cordialement,

EDIT : J'ai compris pour le EAV models, tu es parti dans l'idée où ma solution était de stocké le retour JSON de l'API directement en la BDD dans une colonne du coup. Moi j'étais plutôt parti pour stocker le fichier JSON de l'API dans le serveur directement.