Efficacité table sql

[biboum]

Bonjour, pour mon projet, j'ai une seule base de donnée, mais près de 200tables à l'intérieur, et je n'en serais qu'à la moitié de mes besoins...
J'ai des tables qui ressemblent à id_diplo / diplopaysa / diplopaysb / score.
Et ca fait pas des tables très remplit...mais je ne vois pas comment l'exploiter autrement...
Mais avoir un site avec 500tables dans sa base de donnée, c'est pas un peu...trop ?

PS, c'est pas forcement le bon endroit, mais vu que c'est pas du developpement, et que c'est plus une généralité, bah...

[Holy]

Et y a pas moyen de réduire le nombre de tes tables ? :ninga:

Parce que si je vois bien "diplopaysa", ça veut dire diplomatie du premier pays. Tu n'as qu'à créer un champ "pays" dans ta table "diplomatie".

Enfin, là on ne saurait pas vraiment t'aider sans savoir de quoi se composent tes tables ^^

[biboum]

Bah disons que c'est compliqué ...
Là l'exemple c'est que chaque pays a une diplo avec un autre pays...
donc forcement paysa / paysb / score. Et le score diplo général sera le COUNT de toutes les diplomaties, ...
Mais il y a également 5tables pour le forum.
5pour la messagerie (liste d'envoie, messagerie, clé de cryptage, espionnage)
etc,
Enfin ce n'est pas vraiment une question de rassembler des tables, c'est plus est-ce que ce n'est pas trop lourd...

[Holy]

Voici déjà un article intéressant:
Des bases de données compactes

En terme de clarté, je ne suis pas vraiment certains que ta solution soit vraiment évidente. Si jamais pour x ou y raison tu dois afficher plusieurs données qui se trouvent dans diverses tables, bonjour les jointures. De plus, pour conserver l'intégrité de tes tables, si les données se retrouvent multiplier, ça va être difficile.

A mon sens, il vaut mieux avoir une table "complexe" avec 100 000 enregistrements, que 100 000 tables avec un enregistrements.

D'ailleurs, pour ton "score diplomatie générale", tu vas devoir recourir à pleins de jointures alors qu'avec une bête requête + count() tu fais la même chose. Enfin c'est un choix de programmation, mais je suis assez perplexe :melanger:

[biboum]

Hummm, jusqu'à présent j'ai réussit à toujours m'éviter les jointures par ce systeme en les faisant plus ou moins chaque module indépendant des autres.
Mais c'est vrai que quand j'ai besoin des jointures..., je sêche toujours un peu vu que c'est bien souvent des triples jointures...

Mais pour les diplomaties, c'est bien ce que je fais un count()...je vois pas ou j'ai dit l'inverse ?

Il y a surement moyen de diminuer certaines parties (genre territoire-population-pollution-etc)
Mais ayant plus de 1000données possible...c'est difficile. Après j'avoue que ca ne fait que 4mois que je bosse dessus et que ma conception des bases de données est encore au stade d'amateur initié, mais pour un énorme projet, combien est une limite acceptable du nombre de table ?

[Holy]

Je vais te répondre franchement: aucune idée.

Je pense que ça dépend en partie des capacités de charge du serveur hébergeant ta base.

Mais pourrais-tu nous montrer une structure type d'une de tes bases, parce que c'est impossible qu'elles ne soient pas réductibles efficacement.

Pour le count() que tu opères pour remplir ta table score, tu dois faire des jointures normalement, si j'ai bien compris comment ça fonctionnait

[biboum]

Une structure type de ma base ? Comment ca ? tu veux voir quoi ?

Hummm non, la table diplo, le score ce n'est pas ca^^


exemple :
id_diplo / diplopaysa / diplopaysb / score
1 / Espagne / France /75(%)
2 / Espagne / Portugal /21(%)
3 / France / Portugal /56(%)


Du coup IN game, la diplo de l'espagne général sera de (75+21)/2 = 48%.
Celle de la France (56 + 75)/2 = 66%
Un SELECT COUNT (score) tout simple quoi...

[Holy]

Okk :good:

Je m'étais complètement fourvoyé ^^ Je viens de piger le truc

Bon, ben comment fais-tu pour avoir 200 tables ? Tu pourrais rapidement faire un descriptif de tes tables ? Pas des 200 mais disons comme tu l'as fait pour les tables concernant le forum.

Parce que dans tous les cas, si de fait la taille de la table dépend en partie du nombre de tables, tu devras réduire celles-ci.

[biboum]

Oula
Bah il y a alliance pour les membres des différentes alliances sur le forum.
Il y micro-alliance pour le nombre de micro posé dans chaque alliance pouvant amener à de l'espionnage du forum...
Le forum en lui même (multi-forum-modération-systeme non-lu/lu)
Les batiments par térritoires
Toute la partie économie (entreprise, bourse, tarif préférentiel, besoin, stock, production, implantation des compagnies, ...)

La messagerie (5tables qui va de la messagerie, les listes d'envoies, les messages espionné, les clés de cryptage des utilisateurs, etc)
la partie administration des membres sur une seule table (profil, inscription, etc)
Rien que là j'en suis à 25tables.
Les différents ministère pour la gestion du pays (10ministeres...10tables...50données différentes dans chaque table)
les coordonnées pour pouvoir gerer la notion de distance entre un pays et un autre.

Comme tu le vois, tout est indépendant, mais vu qu'il y a énormement de possibilités...bah...forcement ca prend beauocup de tables.
Je sais pas si tu vois "Mission président" ? C'est ca en mieux...^^

[wild-D]

question: est-ce que le nombre de pays est limité ou pas ? (soit parce qu'il est fixe; soit parce que tu décide que y aura jamais plus de X pays actifs à un moment donné)

parce que si je comprends la manière dont ta conçu ton gameplay et donc la construction de ta bdd; le point critique c'est vraiment entre autre le nombre de pays (bien plus que le nombre de table).
Or si tu décide de rester en illimité tout en te payant le luxe de nombreuses tables de relation: n<->n, n<->m ou t'as n et m qui tend vers illimité (puisque fct direct du nombre de pays, ou objet auto généré par l'appli) tu pars pas gagnant. (pour n<->n, ok à 10 joueurs ça te fais de lordre de moins de 100 entrée, tranquille, à 1000 joueurs tu passe à un ordre de 1M ça devient déjà moins léger; si t'as le malheur de voir ton jeu devenir un hit à 100'000 d'inscrit tu vas commencer à être mal).

Le jeu à l'air super chindé au niveau de détail/complexité/réalisme du gameplay (ça donne envie de voir). Mais peut-être un peu trop^^ ? C'est peut-être pas la conception des tables qu'est bancale, mais le concept du jeu qu'est trop gros pour ce que tu peux t'offrir.

sinon y a des trucs: t'as une table:
id_diplo / diplopaysa / diplopaysb / score
1 / Espagne / France /75(%)
2 / Espagne / Portugal /21(%)
3 / France / Portugal /56(%)

si t'as d'autre du même genre avec les mêmes "clés" n<->n (la je parle pas de ton id_diplo; mais de ta vrai clé discriminante pour ton entrée (qui détermine donc les nombre max d'enregistrements dans ta table: càd id_pays1 + id_pays2) tu devrais pour rationaliser ta bdd regrouper tes tables sur ces mêmes "clés". (après le soucis sera les lock de ta table si t'as bcp d'écriture et que t'es en mysql avec le moteur myisam)
(parce qu'apparemment c'est possible^^ genre distance entre pays -bon sauf que là je pense pas que mon exemple soit au point, vu que la distance tu l'as par coordonnées des 2 pays; c'est pour le principe-)


si tu peux pas gagner grands chose avec ça; y aura pas de miracle (tu peux toujours optimiser la taille de chaque champs de tes tables aussi; mais au final tu ne résoudra pas le problème premier: ta conception)


comme tu le dis "y a énormement de possibilités"... et c'est bien ça le soucis; c'est que tu as conçu ton gameplay de sorte que tu te retrouve pas seulement à avoir énormément de possibilités; mais surtout c'est que tu dois stocker toutes ces possibilités. C'est là t'as plus grosse erreur.
je sais pas si je suis claire ? Je vais prendre les échecs: t'as un nombre de cases limités (64); un nombre de pièces limités aussi (2*16 et encore moins si on compte par type de pièces). Chaque type de pièces à un nombre de déplacement possible assez limité. Et au départ d'une partie il n'y a qu'une seule disposition possible et que 2 joueurs. ça n'empêche pas que le nombre de parties distinctes possibles soient astronomiques. (aucunes idées de la taille de base de données qu'il faudrait pour toutes les stocker, mais ça doit être mastocke )
Ton problème majeur est donc de faire le contraire; tu n'as pas optimisé ton jeu pour maximiser l'efficience des possibles. T'es parti du "plus j'aurais de bidules" plus mieux ça sera.(et tu semble restreindre au max le champs des possibles: la diplo entre 2 pays ce sera "juste ça" et tu conclusur le concept de stocker autant de possibilité que possible).

d'après moi t'as zapé dans ta conception (ton gamedesign) le point ressources techniques et matérielles disponibles^^ (je vais te dire que t'es pas le seul; moi ça me saoule quand je conçois mes petits truc d'y consacré du temps; je me le répète à chaque fois que je me fais avoir: l'optimisation ça commence pas quand on code, mais quand on conçoit).

enfin bon je suis pas le mieux pour juger; j'en suis qu'à la conception de mon premier jeu ... je risque de faire moins le malin dans quelque temps ^_^'