[Mysql] Statistiques pour un jeu - Problème de place (ou de logique ^^)

Salut à tous.

J’ai fait un petit jeu pour apprendre à reconnaître des caractères japonais (et bientôt du vocabulaire).

Ce jeu est fait en php et je fais des sauvegardes des scores pour chaque partie dans une base mysql. Je sors ensuite des statistiques simples sur le score et les erreurs.

Mais cela ne me satisfait pas.

J’aimerais que le joueur puisse avoir accès à des statistiques détaillées (pour chaque mot/caractère, le nombre de fois que le joueur a eu juste, faux, et que le mot/caractère est apparu dans le jeu).

Et c’est là que j’ai un petit problème.

J’ai réfléchi mais je n’arrive pas à visionner une solution qui ne prendrait pas trop de place (dans la base).

C’est peut-être juste une question de réflexion mais je ne trouve pas…

Si vous aviez une idée ^^.

Pour résumer, il me faut donc les statistiques de chaque mot pour chaque joueur.

Mes idées:

  1. Créer une table pour chaque joueur avec à l’intérieur de celle-ci le mot et ses stats (mais s’il y a beaucoup de joueurs, il reste d’y avoir beaucoup de tables :paf: ).

  2. Dans la table "joueurs", ajouter une colonne pour chaque mot avec leur stats (Juste|Faux|Sortis) (-> Beaucoup de colonnes, il peut y avoir 10 000 mots… donc 10 000 colonnes :pt1cable: … En même temps, pour la solution 1, ça ferait joueur * 10 000…).

Voilà…

Si vous avez mieux, dites-le moi. Je n’arrive plus à réfléchir :sleep:

Merci d’avance :).

Je ne sais pas comment tu fonctionne, mais tes kanjis peuvent être stocké dans une table caractere(id, kanji), et tu n’as qu’à faire la relation avec la table des scores.

Et tu auras bien 10k enregistrement si le joueur a testé tous les kanjis :slight_smile:

Ceci dit, tu n’as guère de choix…

Merci pour ta réponse Sans-Nom.

Dans ce cas, il y aura 10 000 enregistrements par joueur (s’ils ont vu les 10 000 mots?).

Pour l’instant, dans ma table des scores, il n’y a aucune info concernant les kanji. (juste des stats des scores et autres).

Je vais d’abord essayer avec quelques mots, mais… Je me demande combien supporte une base mysql ^_^…

Ca peut tenir au moins jusqu’à 1 million de données (donc 1000 joueurs dans ton cas). Après, faut voir les contraintes que tu apportes sur la base.

Ok, merci. Un million de données, c’est un million d’enregistrements, c’est ça?

En fait, je pense faire plusieurs tables de statistiques suivant les différents types de jeu. La plus importante sera celle concernant un certain type de vocabulaire (avec les fameux 10 000 mots).

J’ai peut-être une idée (grâce à toi ^^). Je vais voir ce que je peux faire quand je serai chez moi :).

Si au bout d’un moment, ma base ne peut plus tenir de données, j’en créerai une autre. Je pense que pour le moment, ça ira. Je pense que rares seront les personnes à atteindre les 10 000 mots. (je sais qu’il faut prévoir, mais dans la limite de ce que les “logiciels” ou “outils” supportent). Pour les bases, je peux en créer autant que je veux chez mon hébergeur actuel… (Bon, je ne sais pas non plus -pour le moment- comment je ferai pour passer sur l’autre base au cas où… Mais je verrai ça plus tard).

A propos du nombre de données, je viens de lire ceci sur un topic (ici)

Si c’est bien çà, je devrais être tranquille (faut voir si le serveur ne rame pas trop après ^_^).

Il faut créerr un index sur ta table pour pas que les requêtes rament. (indexer sur la clef)

deltree, merci pour ta réponse ^^.

J’ai lu un petit tutorial cet après-midi à propos des index. Ils disent de les créer sur là où il y a le plus grand nombre de requêtes et de les éviter lorsqu’il y a beaucoup d’update.

C’est bien ça? ^_^.

Je pense donc que dans mon cas, il me faudra créer des index sur le nom des joueurs (au moins ^^).

Je ne savais pas qu’il y avait des cas ou les éviter, pour moi une table non-indexé, c’est pas de vrai relationnel, ça doit être assez rare (du moins sous oracle).
J’indexerai aussi et surtout ta table de score (la table à un million) si tu veux la requêter, parce que c’est la plus volumineuse, et comme tu va surtout faire des insert dedans, et pas des update, le pbm d’optim que tu évoque ne se pose pas.
Et éviter les requêtes hyper groumande du type select imbriqué (select from select ou autre select…where data in select).
Se limiter aux jointures simples entre 2-3 tables, et uniquement quand tu en as besoin. et indexer donc sur la clef sur laquelle tu compte faire tes requêtes, jointures.
à priori un index sur la clef primaire (qui définira une contrainte sur la table par la même occasion):
CREATE UNIQUE INDEX …

plus un index sur l’id du joueur, un autre sur l’id de la partie (il faut voir le modèle de données)
:slight_smile:

Merci pour ta réponse deltree ^_^.

En fait, je n’ai jamais été très bon en analyse et je perds donc toujours un temps fou en ce qui concerne la création des tables et tout ça O_O.

Pour mes requêtes, ça devrait rester des trucs assez simple, juste des SELECT… WHERE… ORDER BY… (pour ce qui est du jeu, car plus j’avance et plus j’ai d’idées… pour d’autres fonctionnalités sur mon site ^^).

Je vais revoir tout ça ^_^.

J’en reviens à mes stats ^^.

En fait, non, pas vraiment. C’est juste qu’apparemment ce n’est pas “bien” de créer un index sur une clef primaire (d’après phpmyadmin). D’après ce que j’ai lu, une clef primaire est déjà indexée.

Bon, sinon, dans ma table score, je pourrai indexer l’id du joueur (qui est en fait son pseudo!), mais pas de clef primaire (une clef primaire ne peut pas avoir de doublon, n’est-ce pas?). Dans ma table des scores, il y a en effet plusieurs fois les mêmes “id_joueur” avec leurs différents jeux.

Une question me vient l’esprit. Est-il mieux de créer un id numérique plutôt que de n’avoir que le pseudo du joueur comme id? (ce pseudo est unique).

Merci :).

oui normalement une clée primaire est indexée par défaut car unique,

sinon je vois pas non plus comment faire autrement qu’une table résultat par joueur.

joueur info - score joueurs - kanji, sachant qu’il y en a 10 000 qu’elle est la probabilitée qu’il ait été questionné sur les 10 000… :stuck_out_tongue:

donc à mon avis tu ne devrais pas dépassé les 5 000 / joueurs sachant que pour 5000 tuples ca ne te fait pas 1 mo de donné ss mysql je pense que tu as de la marge.

p.s. : tu es mieux de mettre des id ainsi si ton membre change d’info ba tu gère l’id numérique et non un nom => + rapide idem pour tes query entre table

Non, par définition vu que la clef indentifie de manière unique un élément, elle doit être unique, d’ou l’utilisation d’un create unique index.
D’autre part, je ne sais pas comme tu as défini la clef primaire dans ta table . si c’est dans la création de la table, ça doit être déjà indexé, donc évidemment, il ne faut pas recréer l’index.
Sinon en oracle, j’utilise justement le create unique index, pour définir cette clef.

C’est pas obligatoire, d’une part il faut être sûr que le pseudo sera toujours unique(à priori oui), d’autre part, l’id peut-être plus court, et peut permettre de gagner de la place en base, mais avec des pseudo court (genre 12 car), tu ne gagne pas grand chose.
l’autre inconvénient du’ilitser directement le pseudo comme id, c’est qu’il faut considérer qu’il n’est pas modificable: il serait difficile de mettre à jour toutes les tables pour remplacer l’ancien pseudo par le nouveau.
Donc si tu part sur un pseudo relativement court et non modifiable, tu peux l’utiliser comme clef etrangere dans les tables.

:slight_smile:

12 car = 12 octets (et si c’est du multibyte, plus)
1 int (ou bigint) = 4 ou 8 octets

Ca reste conséquent :slight_smile: puis trier des entiers c’est plus rapide que trier une chaîne.

Merci pour vos réponses.

Pour l’id joueur, je n’avais pensé au fait qu’un joueur pourrait vouloir changer de pseudo. (Normalement, je suis le seul à pouvoir le faire). Néanmoins, si je peux gagner un peu de vitesse ici, je le ferai.

MulDy> D’où une autre question. Qu’est-ce qui est plus rapide? Une base avec 1000 tables joueur avec chacune x enregistrements ou bien une base avec une table “stat” qui contiendrait les statistiques de tous les joueurs?
Et… Une question de limite. On peut créer jusqu’à combien de tables?
Je ne sais pas trop comment réagirait mysql au niveau de la rapidité d’exécution (forcément, quand il n’y a pas beaucoup de tables, il vaut mieux avoir les données de chaque joueur dans leur table propre, mais après?).

deltree> Pour la clef primaire, je l’ai définie après la création (avec phpmyadmin…). Lorsque je l’ai indexée, j’ai eu un message d’avertissement me disant que ce n’était pas conseillé (peut-être parce que le fait d’avoir créer la clef primaire avait aussi créé un index ^^).

Sans-Nom> ok ok merci ^^.

http://mysql.com/doc/refman/5.0/en/creating-many-tables.html

Je ne sais pas ce qu’ils appellent créer beaucoup de tables, mais finalement, c’est peut-être mieux de n’avoir que ma table ‘stats’ avec les enregistrements de tous les joueurs?

ce qu’il y a c’est que si tu fais 1 seule table admettons que tu aies 1000 jouers * x essaie qd tu vas faire la statistic d’un joueur tu vas devoir parcourir les 1000 * x valeurs…

tandis que 1j = 1t tu ne boss que sur une donc moins de overload. De toute façon 1 table ce ne sont que des données donc je ne pense pas que tu aies une limite surtout que si on y pense c’est une relation 1 - n donc…

apparament on sait déjà faire des jointures entre 64 tables donc en créer 1000… aucune info la dessus dans le manuel ?