Discussion :

[Invité]

Bonjour,

Je réalise un jeu web et je souhaite découper mon jeu en "parties". C'est à dire qu'un joueur appartient à une partie et ne peut pas interagir avec les joueurs ou éléments des autres parties. Je souhaite limiter une partie à par exemple 500 joueurs (histoire de jouabilité).

Problème : Je bloque lorsque je dois modifier mon schéma pour ajouter les associations avec la partie en cours.

Exemple précis du schéma actuel avec quelques tables :
C'est un jeu de gang, avec une carte pour faire des déplacements.
Tables :
gangs(id_gang, nom, #id_parrain) : Un gang peut avoir un parrain (membre)
carte(abscisse,ordonne, #id_gang) : Une case peut appartenir à un gang
user(id_membre, #abscisse, #ordonne, #id_gang) : Un membre est sur une case, et appartient à un gang


Avec les parties, cela donnerait :
Une table Parties (id_partie, datedebut, datefin)
Une case appartient à un gang dans une partie précise (on aurait un truc genre : abscisse, ordonne, id_partie, #gang)

Mais là... Un membre appartient à une partie... J'aurais id_membre, id_partie... Mais si un membre appartient à une case (d'une partie !), je devrais avoir sa clé primaire composée en clé étrangère donc : id_membre, id_partie, abscisse, ordonne, id_partie ???

Ca me parait un peu étrange et mal modélisé non ? J'ai deux fois l'information des parties ! Et ça m'arrive sur quelques tables, je sais pas trop comment gérer ça.

J'ai tenté de reprendre un MCD mais j'ai actuellement 38 tables et c'est l'enfer de reprendre tout un MCD avec tout ça, en liant tout à des parties.

Avez-vous des solutions pour faire ce que je souhaite ou une proposition pour l'exemple ci-dessus ? (histoire que ça me débloque pour le reste ! )

Merci d'avance à vous !
A bientot

[Richard_35]

Bonjour Nirvv,

Avez-vous des solutions pour faire ce que je souhaite ou une proposition pour l'exemple ci-dessus ?

==> la solution, c'est d'établir des règles de gestion, puis de modéliser (MCD) et, enfin, de déterminer la structure des tables. Il semble que tu aies commencé par déterminer la structure des tables...

Liste des entités :

• Membre
• Gang
• Partie
• Carte
• Case

Règles de gestion (supposées) :

• 1 membre peut appartenir à 0 ou 1 et 1 seule partie ;
• 1 partie peut comprendre 0 ou plusieurs membres ;
• 1 gang possède 1 et 1 seul membre parrain ;
• 1 membre peut être le parrain de 0 plusieurs gangs ;
• 1 partie peut contenir 1 et 1 seule carte ;
• 1 carte peut appartenir à 0 ou plusieurs parties ;
• 1 carte contient 1 ou plusieurs cases ;
• 1 case ne peut appartenir qu'à 1 et 1 seule carte.

Est-ce correct ?

[Invité]

Bonjour Richard35 ! Merci de ta réponse.

J'ai les bases sur le MCD : création des règles de gestion, établir le MCD, respecter les règles pour le passage au modèle physique (association n,n devient table etc.. et j'en passe).
Cependant, j'ai réalisé cette étape au début de mon projet, et étant donné que je suis amateur, bien d'autres choses y se sont greffés depuis. Je suis maintenant avec 38 tables (ce qui correspond à "une partie de jeu" en fait). Lors de cette grosse modification pour le découpage en "parties", ça devient compliqué de reprendre le MCD. Surtout vu les liens, j'avais du mal à le refaire

Pour ta proposition :
A vrai dire, j'ai appelé ma table "Carte", mais elle représentait "Case" : c'était l'ensemble des cases du jeu (A1, A2, A3... J10)

Les règles de gestion que tu as énoncé sont correctes, il y a cependant des petites nuances :
- Un gang a 0 ou 1 parrain (en effet, au début de la partie, les membres sont affectés dans des gangs pré-existants, non créé par un joueur réel donc parrain = null).
- Un membre est parrain de 0 ou 1 gang et appartient a 1,1 gang
- Même carte sur toutes les parties (il y a aussi des bâtiments sur la carte mais on va passer ça)

Et une règle oubliée, qui me gênait :
- Une case peut appartenir à 0 ou 1 gang (c'est à dire que c'est sur son territoire). Je dois donc aussi avoir une liaison sur gang avec la case.


Il faudrait que j'essaye d'instaurer peu à peu ce système de parties sur une partie de mon MCD, tout doucement, au lieu de vouloir tout faire d'un coup. J'ai beaucoup de tables qui doivent être rattachés à la notion de "Partie" : (autre exemple) si un joueur achète une arme sur la partie 1 dans l'armurerie A, cela ne doit pas affecter la quantité dans l'armurerie A de la partie 2. Ca créé donc des liens en plus avec la table Parties.


Au premier post, j'avais donc pensé à une façon d'instaurer ça (après modification) et je voulais savoir votre avis

Merci encore !

[Richard_35]

Et une règle oubliée, qui me gênait :
- Une case peut appartenir à 0 ou 1 gang (c'est à dire que c'est sur son territoire)

==> pour une seule partie ?

En attendant, voici les règles de gestion (modifiées) :

• 1 membre peut participer à 0 ou 1 et 1 seule partie ;
• 1 partie peut comprendre 0 ou plusieurs membres ;
• toutes parties confondues, 1 gang possède 0 ou 1 seul membre parrain ;
• toutes parties confondues, 1 membre peut être le parrain de 0 ou 1 seul gang ;
• toutes parties confondues, 1 membre appartient à 1 et 1 seul gang ;
• toutes parties confondues, 1 gang est composé de 0 ou plusieurs membres ;
• 1 partie contient 1 et 1 seule carte ;
• 1 carte peut appartenir à 0 ou plusieurs parties ;
• 1 carte contient 1 ou plusieurs cases ;
• 1 case ne peut appartenir qu'à 1 et 1 seule carte.

Est-ce OK (en attendant la réponse) ?

[Invité]

Oui pour une seule partie, une case va appartenir à un gang X. Rien ne dit que cette case ne va pas appartenir au gang Y dans une autre partie.

Quant à la règle "toutes parties confondues, 1 gang possède 0 ou 1 seul membre parrain ;", une petite explication :
- Il existe une liste 6 gangs (modifiable que par l'administrateur du jeu). Les gangs ont un champ "type", qui est soit : "Base" soit "Creer" (j'y viens :p ).

- A l'inscription, un joueur choisit : pseudo / mdp / un avatar / un gang parmi les 2 gangs "Base" (ces gangs ont un id_parrain = NULL)

- Il se connecte pour la 1ère fois : il n'a pas de partie, il en rejoint une parmi celles proposées (non pleine).

Lors du jeu, il effectue différentes actions (achat d'armes, frapper autres joueurs, etc...). Il monte de grade au fur et à mesure. Au moment où il devient "Parrain", il peut créer son gang dans sa partie et inviter d'autres joueurs.

Là, lors de la création de gang par un Parrain, j'affiche donc : La liste des gangs "Creer" qui ont un id_parrain = null dans cette partie (c'est à dire qu'ils sont disponibles à la création).

Le joueur le choisit : il en devient le parrain. Il peut désormais inviter des autres membres etc.. Je garde aussi le gang de "Base" au cas où un membre se fait virer d'un membre "Creer" (il revient au gang de base).

Donc, un gang a 0 ou 1 parrain dans une partie précise, et pourra avoir un autre parrain dans une autre partie.

Un ami m'a proposé quelque chose comme ça :

parties ( id_partie [pk], nom_partie ) UNIQUE(nom_partie)
gangs ( id_gang [pk], nom_gang, logo ) UNIQUE(nom_gang)
cases ( id_case [pk], id_partie [fk], absisse, ordonnee, id_gang [fk] ) UNIQUE(id_partie, absisse, ordonnee)
users ( id_user [pk], nom_user, id_gang [fk], id_case [fk] ) UNIQUE(nom_user)
parrains ( id_joueur [pk][fk] , id_gang [pk][fk] )

Une case id_case serait lié à sa partie. Un membre est sur une case (et donc d'une partie précise si on veut la récupérer) et de même pour le parrain : on remonte par le joueur et par la case ensuite si on veut les "gangs disponibles de la partie".

C'est un peu complexe mais ça a pas l'air mal..
On avance ?

[Richard_35]

Bonjour Nirvv,

Tu retombes dans le piège initial de créer la structure des tables avant que les règles de gestion soient clairement énoncées en texte et, donc, que la conception soit arrêtée. D'où en découlera le MCD.

Donc, peux-tu répondre, point par point, par oui ou par non, aux règles de gestion suivantes ?

• 1 membre peut participer à 0 ou 1 et 1 seule partie ;
• 1 partie peut comprendre 0 ou plusieurs membres ;
  
• 1 partie comprend 0 ou n gangs ;
• 1 gang peut être dans 0 ou n parties ;
  
• 1 partie contient 1 et 1 seule carte ;
• 1 carte peut appartenir à 0 ou plusieurs parties ;
• 1 carte contient 1 ou plusieurs cases ;
• 1 case ne peut appartenir qu'à 1 et 1 seule carte ;
  
• 1 gang possède 0 ou 1 seul parrain pour une partie ;
• 1 gang possède 0 ou n parrains toutes parties confondues ;
• 1 membre parraine 0 ou 1 seul gang dans sa partie ;
  
• 1 membre appartient à 1 et 1 seul gang dans sa partie ;
• 1 gang est composé de 0 ou plusieurs membres pour une partie ;
• 1 gang est composé de 0 ou plusieurs membres toutes parties confondues ;
  
• 1 case peut appartenir à 0 ou 1 et 1 seul gang pour une partie ;
• 1 case peut appartenir à 0 ou n gangs toutes parties confondues ;
• 1 gang possède 0 ou n cases pour une partie ;
• 1 gang possède 0 ou n cases toutes parties confondues.

[Invité]

Re-bonjour Richard,

En fait on a quand même discuter et établi des règles de gestion et fini sur ce modèle, mais oui on va reprendre ça "propre".
Alors pour les règles de gestion :

• 1 membre peut participer à 0 ou 1 et 1 seule partie => Oui
• 1 partie peut comprendre 0 ou plusieurs membres => Oui
• 1 partie comprend 0 ou n gangs => Oui
• 1 gang peut être dans 0 ou n parties => Oui
• 1 partie contient 1 et 1 seule carte => Oui
• 1 carte peut appartenir à 0 ou plusieurs parties => Oui
• 1 carte contient 1 ou plusieurs cases => Oui
• 1 case ne peut appartenir qu'à 1 et 1 seule carte => Oui
• 1 gang possède 0 ou 1 seul parrain pour une partie => Oui
• 1 gang possède 0 ou n parrains toutes parties confondues => Oui
• 1 membre parraine 0 ou 1 seul gang dans sa partie => Oui
• 1 membre appartient à 1 et 1 seul gang dans sa partie => Oui
• 1 gang est composé de 0 ou plusieurs membres pour une partie => Oui
• 1 gang est composé de 0 ou plusieurs membres toutes parties confondues => Oui
• 1 case peut appartenir à 0 ou 1 et 1 seul gang pour une partie => Oui
• 1 case peut appartenir à 0 ou n gangs toutes parties confondues => Oui
• 1 gang possède 0 ou n cases pour une partie => Oui
• 1 gang possède 0 ou n cases toutes parties confondues => Oui

Donc on est d'accord sur les règles de gestion !
J'apprécie ton temps pour m'aider, merci :p

[Richard_35]

MCD (à vérifier en fonction des règles de gestion, car vite fait...) :



A noter :

• contrainte d'égalité (=) : pour qu'un membre parraine un gang pour une partie, il faut que ce membre soit participant à cette partie ;
• contrainte d'égalité (=) : pour qu'un membre parraine un gang pour une partie, il faut que ce membre appartienne à ce gang ;
• identification relative (1,1) : Partie_Gang dépend relativement de Partie et de Gang (le couple {IdPartie, IdGang} fait partie, d'office, à l'identifiant de Partie_Gang).

Je te laisse analyser ce MCD dans le détail. Ensuite, nous verrons la structure des tables finales.

[Invité]

Re !

J'ai bien regarder ton MCD. Bon, il y a quelques petits trucs avec lesquelles je suis pas forcément à l'aise car j'ai toujours fait des MCD très simplistes mais ça va .

Au final, je ne sais pas s'il est utile de rajouter une entité Carte ?

En effet, une case va être (abscisse/ordonne) : A1, A2, A3 etc.. Et va appartenir à 0 ou 1 gang dans une partie précise. On est d'accord.
Mais chaque partie va avoir 1 carte qui sera exactement la même toute partie confondue : la partie 1 ou la partie 2 auront le même nombres de cases. (Je m'étais peut-être mal exprimé auparavant).

Dans ce cas là, ne peut-on pas omettre l'entité Carte et rattacher directement Parties à Cases ?

Je viens de re-regarder, et je capte le principe :p

[Richard_35]

Au final, je ne sais pas s'il est utile de rajouter une entité Carte ?

==> créer une entité Carte pourrait te permettre, à l'avenir, de disposer de plusieurs cartes. Cette entité "ne mange pas de pain" et, en plus, elle sert à regrouper plusieurs cases. De ce fait, tu pourrais affecter des attributs particuliers à une carte (couleur, ...), donc pour toutes les cases qui la composent. Sinon, donc sans l'entité de regroupement Carte, tu seras obligé de dupliquer le même attribut dans toutes les cases.

[Invité]

C'est un argument valable effectivement :p
Je tente de passer moi-même à une structure finale des tables ou tu me proposes quelque chose ?
L'idée c'était vraiment que je puisse m'appuyer sur l'exemple de ces 4 tables pour le comprendre et appliquer ça sur toutes mes tables restantes (quitte à reprendre les règles de gestion et un MCD !) !

[Richard_35]

Voici les tables résultantes (à vérifier, car vite fait...). Souligné=PK, #=FK :

(1)

Membre(IdMembre, …)
Gang(IdGang, …)
Carte(IdCarte, …)
Case(#IdCarte, Abscisse, Ordonnee, …)
Partie(IdPartie, #IdCarte, …)
Partie_Gang(#IdPartie, #IdGang, #IdMembreParrain, …) ==> si #IdMembreParrain jamais NULL
Partie_Gang_Membre(#IdPartie, #IdGang, #IdMembre, …)
Partie_Gang_Case(#IdPartie, #IdGang, #IdCarte, #Abscisse, #Ordonnee, …)

Sinon :
(2)

Partie_Gang(#IdPartie, #IdGang, …)
Partie_Gang_Parrain(#IdPartie, #IdGang, #IdMembreParrain, …)

Ou :
(3)

Partie_Gang(#IdPartie, #IdGang, …)
Partie_Gang_Membre(#IdPartie, #IdGang, #IdMembre, Parrain-booléen, …)

Ma préférence va pour la deuxième proposition.

[Invité]

J'aime bien également la deuxième proposition (pour les parrains, je vois ça plus clairement).
Par contre là, comment je connais la position d'un membre ? Il me semble qu'on ait oublié ce point dans le MCD maintenant que je vois les tables finales.. (j'ai plus de facilité à analyser les tables de cette façon qu'un MCD )

Un membre doit être situé sur 1 et 1 seule case.
Et un membre du gang A, peut évidemment se situer sur une case qui appartient au gang B. (ça, je pense que t'avais compris !)

Le truc, c'est que si on dit "un membre est sur 1 et 1 seule case", ça va faire quelque chose du genre :
Membres(id_membre, #IdCarte, #Abscisse, #Ordonnee) puisqu'on doit récupérer la PK de Case ?

Qu'en dis-tu ?

Je sais que c'est une mauvaise pratique en conception de BD (à priori), mais on m'avait proposé de mettre un nouvel ID "id_case" pour la table "Case" (et mettre id_carte,abscisse,ordonne en UNIQUE) sinon..
Ce qui donnerait :
Membres(id_membre, #id_case).


Merci encore de ton aide
On approche !

[Benzouye]

Bonjour,

J'ai participé à cette réflexion avec Nirv, du coup je me permet de venir apporter ma pierre à l'édifice certes sans réelle expertise, mais avec amateurisme ...

Je rejoint Nirv sur l'intérêt de créer une clé primaire id_case pour simplifier la structure de données de la relation "membre est sur case".

Ensuite je simplifierai aussi la relation "membre est dans un gang et peut en être le parrain" en créant simplement une FK id_gang dans la table membre avec un booléen parrain.

Je comprend tout à fait l'hérésie que ces remarques représentent en terme de respect des règles de gestion puisque l'on ne pourra pas assurer leur respect directement par le SGBD, mais elles apportent une vraie simplification du modèle ...

[Richard_35]

Bonjour Nirvv et Benzouye,

Ensuite je simplifierai aussi la relation "membre est dans un gang et peut en être le parrain" en créant simplement une FK id_gang dans la table membre avec un booléen parrain.

==> c'est possible. Mais, à l'avenir, peut-être faudra-t-il prévoir qu'un membre participe à plusieurs parties. D'autre part, l'intérêt de :

Partie_Gang(#IdPartie, #IdGang, …)
Partie_Gang_Parrain(#IdPartie, #IdGang, #IdMembreParrain, …)

réside dans le fait qu'il sera possible, à l'avenir, d'affecter des attributs propres aux parrains des gangs d'une partie. Par exemple, la date/heure à laquelle le membre est devenu parrain du gang pour cette partie. Sans cette table, les futurs éventuels attributs devront être affectés à la table Membre que tu évoques et ne concerneront QUE les parrains, donc un alourdissement d'attributs NULL pour tous les membres qui ne sont pas des parrains.

Je sais que c'est une mauvaise pratique en conception de BD (à priori), mais on m'avait proposé de mettre un nouvel ID "id_case" pour la table "Case" (et mettre id_carte,abscisse,ordonne en UNIQUE) sinon..
Ce qui donnerait :
Membres(id_membre, #id_case).

==> c'est possible, effectivement. Il ne faut oublier de rendre unique {id_carte, abscisse, ordonne}. Là où cela me gêne un peu, c'est que, dans la vie de l'application il ne faut jamais oublier de rendre unique {id_carte, abscisse, ordonne}, au gré des différentes améliorations et de travail sur d'autres index. Alors que, en laissant {IdCarte, Abscisse, Ordonnee} en clé primaire, nous sommes certains que cela ne bougera pas. Mais bon, c'est possible.


Enfin, Nirvv, souhaites-tu que les déplacements successifs d'un membre soient enregistrés (par exemple pour pouvoir annuler un déplacement) ?

[Invité]

Merci pour vos apports

Non, je ne souhaite pas garder les déplacements. Ces derniers sont rapides sur la carte (de l'ordre de 20 a 60sec) et ne sont pas annulables .
A priori, un membre ne pourra jouer que sur une seule partie. Et cela tout le temps.
Le but de ce découpage en parties est de pouvoir rendre le jeu plus lisible, plus ergonomique, en ayant une carte réduite (concentre l'action) et pas trop de joueurs dessus.

Le multicompte est interdit pour des raisons évidentes de fair-play (sinon on pourrait rejoindre sa propre partie et taper ses multicomptes pour augmenter ses caractéristiques).
Le but c'est de faire un jeu d'équipe en quasi temps réel : des actions quand les joueurs sont connectés en même temps.

Voilà :p

[Richard_35]

OK.

Le déplacement nous ramène vers les règles de gestion :

• 1 membre participant à une partie peut être dans
  
  0 ou 1 seule case ;
  0 ou plusieurs cases.
• 1 case peut contenir
  
  0 ou 1 seul membre ;
  0 ou plusieurs membres.

Rayer les mentions inutiles...

[Invité]

Re !

Le déplacement nous ramène vers les règles de gestion :
1 membre participant à une partie peut être dans

• 0 ou 1 seule case ;
  
• 0 ou plusieurs cases.

1 case peut contenir

• 0 ou 1 seul membre ;
• 0 ou plusieurs membres.

Comme ça ! :p

[Richard_35]

Donnant :

Membre(IdMembre, …)
Gang(IdGang, …)
Carte(IdCarte, …)
Case(#IdCarte, Abscisse, Ordonnee, …)
Partie(IdPartie, #IdCarte, …)
Partie_Gang(#IdPartie, #IdGang, …)
Partie_Gang_Parrain(#IdPartie, #IdGang, #IdMembreParrain, …)
Partie_Gang_Membre(#IdPartie, #IdGang, #IdMembre, …)
Partie_Gang_Case(#IdPartie, #IdGang, #IdCarte, #Abscisse, #Ordonnee, …)
Membre_Partie(#IdMembre, #IdPartie, ...)
Membre_Partie_Case(#IdMembre, #IdPartie, #IdCarte, #Abscisse, #Ordonnee, ...)

[Invité]

Je n'arrive pas à saisir l'intérêt de créer les tables :
Membre_Partie(#IdMembre, #IdPartie, ...)
Membre_Partie_Case(#IdMembre, #IdPartie, #IdCarte, #Abscisse, #Ordonnee, ...)

Certes, je pense que c'est comme pour les autres tables, une raison d'évolutivité et de clareté aussi. Mais si on met :
Membres(IdMembre, #IdCarte, #Abscisse, #Ordonne)
On peut retrouver la partie d'un membre dans :
Partie_Gang_Case(#IdPartie, #IdGang, #IdCarte, #Abscisse, #Ordonnee, …)
Avec une jointure, vu que le membre sera sur une case, qui appartiendra elle-même à une partie précise, forcément. Non ?

(EDIT : Ah le MCD ne s'affichait pas. D'accord, donc en fait ça correspond à la création des tables suites au MCD que tu as proposé ! Je comprends la proposition du coup . Je pense que je vais tenter ça ce soir ! Instaurer ces modifications. Ca risque de me prendre quelques heures, donc je reviendrais certainement demain ou dimanche si j'ai des soucis )