[SQL] Casse-tête bastions/unité

[Holy]

Yop tout le monde

Je viens requérir vos précieux conseils parce que je suis tombé sur un sacré noeud ^^

Pour faire simple, mes joueurs peuvent avoir des unités de différents types (actuellement 6 types) qui peuvent être "casernées" dans différents bastions sur la map

Jusque là rien de bien compliqué, sauf que pour taper une table sql cohérente et facilement gérable, j'ai un peu de mal.

Auparavant, il n'y avait que deux "statuts" pour les unités: Aux côtés du héros/En garnison à la capitale. Donc j'avais une table avec cette structure:
player | pattern (type de l'unité) | state (qui valait soit H, soit G)

De cette manière, ça me donnait 2*6 = 12 rangées par joueur. Mais si j'utilise cette structure avec le système de bastion qui peut aller jusqu'à 9 ou 10 bastions, ça devient conséquent par joueur: 9*6 = 54 par joueur.
(J'ai 130 joueurs actuellement, ça ferait 7000 entrées)

Et ici je parle de 6 unités, mais le jeu existe depuis à peine un mois et j'ai pas vraiment eu le temps de me consacrer à la création d'unités :hospital:

Donc, j'ai voulu tenter de modifier la structure en me disant que dés que je rajouterais un bastion, je rajouterai une colonne, comme ceci:

player | pattern | HER (auprès du héros) | SUL (en garnison à Sulysk) | OST (en garnison à Ostonessa) | ...

Le problème de ce type de structure, même si elles permettent de largement diminuer le nombre de mes entrées, c'est pour gérer les requêtes et autre. Puisque selon les factions certains bastions sont accessibles et d'autres pas. Ce qui ne facilite pas du tout le traitement des requêtes (beaucoup de bricolages en tout cas).

Je sais pas si j'ai su être très clair. J'ai pas beaucoup d'expérience de l'utilisation des bases de données à grande échelle, mais est-ce que 100 entrées de 3 colonnes relativement "pauvres" en contenu (int et varchar assez court) pour un joueur, c'est beaucoup ? Evidemment, ça fait rapidement monter l'auto-increment, mais à part ça, en termes de perfs ?

Merci d'avance pour vos éclaircissements

[Anthor]

Te prend pas la tête pour si peu

[Ruz]

Euh... je vais répondre juste en tentant de voir claitr dnas tes relations, pour le nombre, etc... on verra après, hein ^^

Tes unités peuvent etre:
- avec héros
- Garnisons diverses (Capitale ou bastion)

D'une part, je suppose que tu as 3 tables initiales:
* table joueur (ID, Nom, etc...)
* table Unite (ID, Nom, carac, etc..)
* table Garnison (ID, ID_Joueur, Nom, lieu, coordonnées, c'quetuveux...)

un joueur peut donc avoir un héros (Q1: donc, t'as une table héros? plusieurs héros ou unique?).
Des unités, tu les formes, et tu les mets au choix pour te défendre, en garnison, ou auprès du héros...

Q2: Un joueur peut-il perdre une garnison au profit d'un autre?

A ce niveau, je gérerait ainsi, en première idée:

1) Création d'une garnison par un joueur => enregistrement dans table garnison, avec ID + ID_joueur (la garnison est à ce joueur là)
2) unité crée... forcément à un endroit. Si à la capitale => ajout garnison de la capitale, ou au héros, mais les lier direct à un truc.
pour mémoriser ce lien: une autre table (unite_garnison)
ID_ref => ID de la garnison ou héro lié
ID_unite => ID du type d'unité
Champ_non_nommé (H, G) => Héro ou garnison (je sais pas comment fonctionnent tes héros)
Qtt
etc...

pour les déplacements de troupe, ben, transfert de Qtt d'une ligne à une autre.

Quand au volume, avec des index bien placés, pas de soucis ^^
Bon, ben, ca répondrait à ta question, cette structure?

[Holy]

Je répondrai plus tard à Ruz parce que je dois partir ^^

Te prend pas la tête pour si peu

Daaah, ça veut dire quoi ça ? Que je peux "bourriner" sur ma table SQL ?

[Allwise]

Salut, je pense que tu n'abordes pas le problème de la bonne façon. Lorsque tu penses ta base de données, tu dois te demander quel est le meilleur moyen pour stocker tes infos de manière organisée, structurée, et éventuellement évolutive.

Il ne faut pas confondre les entités et les champs. Tu ne devrais jamais avoir à rajouter des champs pour des données qui sont des occurrences. Les champs sont réservés aux propriétés.
Pour ton problème par exemple, les bastions sont des entités, non pas les propriétés d'une map ou autre.
D'après ce que j'ai compris :
un joueur a des unités.
les unités sont dans des bastions
il y a plusieurs bastions sur une map. ( y a plusieurs maps ? )
une unité peut être de différents types.

Donc a priori, je verrais un truc comme ça :


En ce qui concerne les performances, il vaut mieux avoir deux tables liées, qu'une table avec plein de champs, car dans ce cas, tu as pour tous tes enregistrements un tas de champs inutilisés qui alourdissent tes requêtes.
Une table avec 100 enregistrements est insignifiant. Tu pourrais multiplier ce nombre par 100, 1000, 100000 ça ne poserait pas de problème ( à condition d'utiliser convenablement les index ).

Si tu as de la motivation et du temps, tu peux te pencher sur MERISE, un ensemble de méthodes qui t'aident à faire ta base de données en partant de tes besoins.

Edit :
A la lecture du post de Ruz, je me rends compte que j'ai pas pris en compte la possibilité pour les unités d'être avec le héros, mais ce serait pas compliquer à gérer

[Seren]

Je voudrais étendre un peu la question de holy.

Dans mon ébauche de conception j'ai des tables qui sont de taille NxN, avec N étant le nombre de personnages joueurs.

Par exemple, les relations entre deux personnages donnés, si ils sont alliés, adversaires etc...

Ce qui me fait peur c'est que dans le pire cas:
avec N=100, ça fait déjà 10 000 entrées
avec N=1000, ça fait 1 million d'entrées.

Franchement je ne vise pas 1000 joueurs, et il est très possible qu'un joueur n'est pas de relation avec tous les autres joueurs, mais quand même ça me fait peur.

Mais je ne sais vraiment pas comment éviter une table NxN dans un cas pareil. Il y a des astuces, ou il faut abandonner ce genre de fonctionnalité ?

[wild-D]

si j'ai bien compris pour économiser le nombre de ligne... tu explose le nombre de colonnes ?!

je suis pas sûr que ce soit super rentable; je m'explique; à priori un joueur pourra facilement posséder une unité de chaque type^^;
par contre peu de chance qu'il occupe tout les bastions de la carte. je me trompe pas ? et encore moins de chance qu'il ait de toutes les types d'unités dans tous les bastions.
(enfin je connais pas bien ton jeu; juste visité le compte démo pour voir )

donc théoriquement ça signifie que tu auras bcp de colonne vide (à zéro - soit innaccessible/soit que le jouer à pas de ce type d'unité dans ce bastion).

enfin la question qui va être aussi importante est quelle évolution tu prévois pour ton jeu (augmenter les bastions oui/non ? ou augmenter les races ?)


moi ce qui me fait pencher pour que tu garde le système précédent;
1) c'est que c'est bcp plus souple (ajout de nouveau type unité/bastion se fait sans modifier la structure de la table)
2) tu as dis que tous les bastions n'étaient pas accessible selon le clan du joueur; donc tu n'as pas pour ton nombre d'entrée un facteur multiplicateur de 9 ou 10 bastion; mais un facteur correspondant au nombre de bastion accessible. (donc qui oscille entre 0 et 10... sachant que si il est de 10 pour un clan; ça signifie qu'il est de zéro pour l'autre clan^^ ce qui fait que ton nombre d'entrées maximum est bien moindre que ce que tu avance). En plus je sais pas comment ça se passe au niveau des unités; mais je suppose que c'est pareil; un joueur risque de pas avoir toutes les unités dans tous les bastions (donc même si t'as un facteur max de 6; bien possible que dans la pratique le chiffre moyen par joueur soit bien en-dessous de cette valeur).

(le principe étant bien sûr que si tu garde cette structure, tu t'amuse pas à stocker les champs à zéro; donc c'est un tas d'entrée que tu n'as pas; qui dans ton autre table correspondent à des valeur que tu es obliger d'avoir à zéro^^)


et sinon t'occupe pas autant du nombre d'entrée... t'as déjà vu la structure des table d'un forum^^ ? En général on se préoccupe pas trop que l'on ait des dizaine, ou des centaine de milliers de message dans la table.

edit:
seren même punition^^
normalement tu as effectivement une table avec un potentiel de nombre d'entrée de NxN;
si N = 10; jeu petit, tous les jouers se connaissent; forte chance que tous les joueurs soit en relation les uns avec les autre à un moment et donc d'avoir une valeur "personnalisée" pour la relation.
si N = 1000; y a bien des chance que nombre de joueurs ne soient jamais directement en contact... ça signifie que t'as relation a priori est à la valeur "par défaut" donc en théorie pas obligé que tu stock cette donnée; tu la déduis implicitement plutot qu'un stockage explicite. (enfin moi c'est comme ça que je ferais).
bref; même si t'as bien une table NxN; mais que tu sais que tu n'aurais pas un nombre d'entrée NxN; mais NxM avec M<<N; c'est franchement pas un problème, tu pourrais tout ausssi bien avoir N = 10'000 joueurs. (re-edit: l'astuce ptit plus, en fait c'est de voir si tu peux faire du "garbage collecting"^^; je m'explique: genre que l'état de la relation avec le temps revienne à la valeur par défaut - ex: 2 joueurs ont été adversaires sur un champs de bataille, leur status de relation passe à ennemi; mais depuis longtemps (mois, années ?) ils ne se sont plus croisés; est-ce qu'il sont encore ennemis ou pas ? -est-ce qu'ils ont la mémoire courte ou bien sont très très rancuniers ^^-)

[Holy]

J'ai lu le message de Wild (désolé pour All et Ruz, j'dois absolument y aller), et ok, tayo tayo, je fonce

J'avoue que je préfère également à 900% cette solution, c'est beaaaucoup plus facile à gérer, et c'est moins casse-tête :good:

Merci beaucoup pour vos réponses rapides en tout cas ^^

J'apprends énormément depuis que je suis arrivé sur ce forum

[Allwise]

Je voudrais étendre un peu la question de holy.

Dans mon ébauche de conception j'ai des tables qui sont de taille NxN, avec N étant le nombre de personnages joueurs.

Par exemple, les relations entre deux personnages donnés, si ils sont alliés, adversaires etc...

Ce qui me fait peur c'est que dans le pire cas:
avec N=100, ça fait déjà 10 000 entrées
avec N=1000, ça fait 1 million d'entrées.

Franchement je ne vise pas 1000 joueurs, et il est très possible qu'un joueur n'est pas de relation avec tous les autres joueurs, mais quand même ça me fait peur.

Mais je ne sais vraiment pas comment éviter une table NxN dans un cas pareil. Il y a des astuces, ou il faut abandonner ce genre de fonctionnalité ?

Vu que tu envisages de lier les joueurs entre eux, je pense qu'il serait judicieux de penser un état par défaut, par exemple "neutres", qui existerait en l'absence d'enregistrement dans ta table N<==>N, et de n'enregistrer que les relations qui existent réellement. Il est très peu probable que tous les joueurs soient liés à tous les joueurs, donc tu n'arriveras jamais à un 1000x1000 si tu as 1000 joueurs.

[Seren]

Vu que tu envisages de lier les joueurs entre eux, je pense qu'il serait judicieux de penser un état par défaut, par exemple "neutres", qui existerait en l'absence d'enregistrement dans ta table N<==>N, et de n'enregistrer que les relations qui existent réellement. Il est très peu probable que tous les joueurs soient liés à tous les joueurs, donc tu n'arriveras jamais à un 1000x1000 si tu as 1000 joueurs.

OK merci, c'est ce que je comptais faire de toute façon, c'est juste le côté potentiel du problème qui m'inquiétait.

edit : merci aussi pour l'avis de wild-D.