Grosse(s) table(s) (nouveaux éléments)

[Argorate]

Evidament, tu update plus vite une able avec 2 champs qu'une table avec 25 champs...

et sinon a quoi bon une table terrain? Tout se qui concerne les terrains cela se met en fichier normalement...

A part si c'est la map, mais dans ce cas pourquoi 7 champs?

[Cartman34]

Argorate --> j'en suis pas sur !
Modifier 20 champs dans une entrée prend PEUT ETRE plus de temps que 5 champs mais je doute que modifier 1 champs parmis 20 prennent plus de temps qu'un champs parmis 5.

[Sephi-Chan]

Evidament, tu update plus vite une able avec 2 champs qu'une table avec 25 champs...

Ce n'est pas ce que semble avoir constaté IGStaff. En fait, ça doit surtout dépendre du nombre de champs que tu modifies, pas du nombre de champs que compte la table en tout.

Il faut aussi avoir en tête que tu es obligé de mettre à jour tes tables une par une. Alors qu'une table unique te permettrait de tout mettre à jour en une seule fois.


Sephi-Chan

[Zamentur]

Ben moi je ferais çà en 1 table vu le système décris.
Sauf si les taux des ressources sont unique pour un joueur, et qu'un joueur peut avoir plusieurs terrain.

En termes de temps, il sera beaucoup plus important de regarder à mettre des clef efficaces sur tes tables, de choisir des types optimisés (genre éviter les varchar pour un champs booléen o_O) ou encore de ne pas mettre en buffer la requête si ce n'est pas nécéssaire...

En termes de lisibilité: une table çà fait beaucoup moins de jointure, donc c'est mieux.

En termes d'évolution, çà me semble pas nécessaire de dissocier sauf si un taux de ressource pourrait être commun ou pas etc...
Par contre pour joueur et personnage il faut laisser car avec une table personnage tu gardes la possibilité d'assigner plusieurs personnage à un joueur... Évolution de la relation hasOne cité plus haut, c'est ce qui se cache derrière le conseil de Sephi-Chan.

[manip]

et sinon a quoi bon une table terrain? Tout se qui concerne les terrains cela se met en fichier normalement...

Bah chaque joueur reçoit un terrain quand il s'inscrit, donc il faut bien que je stocke les données quelques parts :/ (id, nom, id joueur, emplacements, superficie etc rentrent dans la table car chaque terrain est différent, et les emplacements sont liés à la superficie)

Pour ce qui est du personnage, chaque joueur aura un et uniquement un seul personnage, puisque c'est cela même que le joueur incarnera dans le jeu.


Pour les ressources et les taux ils ne sont pas propre au joueur mais bien au terrain. Donc si le joueur a plusieurs terrains, il a plusieurs ressources et donc par conséquent plusieurs taux de productions. Bon finalement je vais surement opter pour une seule table d'après ce que vous me dites

[khiguard]

En fait, si tout tes champs de la table ne demanderont aucune insertion, modification, effacement par les joueurs alors d'accord, tu peut tout mettre dans une et unique table.

Mais il existe des lois, qui existe depuis le fondement du SGBDR et qui sont utilisée depuis , qui tipule: Un Système de table doit être le plus petit possible. Il faut diviser les tables au maximum jusqu'à ce qu'elles ne soient plus possible de les diviser.
La perfection en terme de performance en SGBDR est donc dans la multiplicité des tables.
Bien entendu, on est pas obliger d'arriver a cet extrême

Je vais conseillé, au contraire de ce que j'ai lu, de diviser tes tables. Tu a 3 en têtes, et bien fait en 3. Ca me semble très bien. Mettre 88 champs dans une table comme j'ai lu plus haut est une ennorme erreur si la table est fortement sollicité dans le jeu
Si il est vrais, et je suis totalement d'accord, que le nombre de champ n'influence pas sur le SELECT, il faut savoir que lorsque tu fait autre chose, un UPDATE, un DELETE ou un INSERT, ta table se lock et il faut que le traitement de la demande soit terminer pour qu'une autre demande soit autoriser.
Donc si tu a 20 joueurs en même temps sur ton jeu, que le premier fait une modification dans ta table, celle qui contient aussi la map de ton jeu, les 19 autres doivent attendre que l'UPDATE soit finie pour faire leurs SELECT pour afficher soit la carte (lors de déplacement par exemple) soit pour afficher les caractéristiques du terrain.
Ce qui risque d'être une grande perte de performance pour ton jeu.

A toi de voir.
@+

[Argorate]

Je vien de tester un peu, UPDATE un champ dans une table de 3 champs et UPDATE 1 champs dans une table d'une 20ene de champs a pris (traitement: 0.0002 sec.) dans les deux cas [avec MySQL], et également la modification de 17 champs a encore pris (traitement: 0.0002 sec.), donc soit la difference ce fait avec plus de chiffre apres la virgule donc on ne le remarque pas, soit cela prend sensiblement le meme temps pour tous...

[Ter Rowan]

yop il manque des éléments dans ton étude :

combien y avait il d'enregistrements ? tous les champs étaient ils remplis ? De quelles tailles étaient ils ?


en effet si tu fais un test avec peu d'enregistrement tu ne verras probablement pas grand chose

si tu le fais avec beaucoup d'enregistrements, bien remplis alors là on peut conclure

[Cartman34]

khiguard -> il n'est dit nulle part dans la doc que les tables sont verrouillées.
Dans tous les cas, il y aura moins de chance d'avoir une erreur sur une requete plutot que sur 3.

Je me suis un peu renseigner sur la normalisation des tables.
En effet d'après ceci: http://sqlpro.developpez.com/cours/optimiser/#L5
Il faut les faire les plus petites possibles mais dans l'idée que certaines données sont réutilisées !

Pour ma part, j'ai certes une table avec 88champs mais
1 c'est pas moi qui l'est faite...
2 ça fonctionne très bien ainsi
3 Pour cause, une entrée n'est que rarement demandée par plusieurs personnes simultanément

Ter Rowan -> Ce que tu as dit est pertinent mais s'il a fait les tests avec 5 entrées et que ces 5entrées révèlent une différence notable, cela est suffisant.
Seulement, si ces tests ne montrent que peu de différence, il faut augmenter le nombre d'entrées.
Donc Argorate, le nombre d'enregistrements est il suffisant ?

[Sephi-Chan]

Pour ma part, j'ai certes une table avec 88champs mais
1 c'est pas moi qui l'est faite...
2 ça fonctionne très bien ainsi
3 Pour cause, une entrée n'est que rarement demandée par plusieurs personnes simultanément

Les deux premiers arguments sont… Énormes. :p

La normalisation des bases de données est importantes, mais on ne peut pas diviser pour diviser, il faut que ça ai un sens. À priori, et à moins de nous donner toutes les clés pour le faire, l'auteur du sujet est le seul à pouvoir décider s'il juge bon ou non de procéder à cette division.

À mon sens, c'est la lisibilité/maintenabilité qui doit être privilégiée. L'optimisation des performances doit se faire sur une base solide, pas une base bancale que l'on a posé dans l'idée de faciliter l'optimisation.


Sephi-Chan