Discussion :

[Sereine]

Je suis en train d'écrire tout ça :x

Bah ce qui change, c'est la complexité du schéma :/
de passer à des tables qui gère toutes les caractéristiques en une fois à une table qui va d'abord répertorié les caractéristiques, puis une autre qui associe des valeurs à celle ci, puis une autre qui va ajouter des valeurs supplémentaires ...
je trouve ça compliqué, et plus c'est compliquer, plus ça va être la galère à coder pour moi derrière ...
Je comprends pas pourquoi se compliquer la vie alors que les caractéristiques sont fixes.
Et dans mes règles, c'est bien fixe, donc si je veux modéliser ce que disent mes règles, il n'y a pas de raisons de prévoir des caractéristiques dynamiques.
Car dans tous les cas une fois que ces caractéristiques sont déclarées, elles ne doivent pas bouger, je pourrais pas rajouter à tous les joueurs une caractéristiques en plus en cours de jeu, pas pour des raisons techniques, mais simplement car on ne modifie PAS la base d'un jeu, sous peine de perdre ses joueurs, de modifier leur gameplay et leurs habitudes.

[tse_jc]

Bonjour,

je trouve ça compliqué, et plus c'est compliquer, plus ça va être la galère à coder pour moi derrière ...

Bien que de trouver cela compliqué est en soi très subjectif, permettez-moi d'intervenir sur ce que vous dites ensuite, à savoir que plus un mcd est déplié et "complexe" plus c'est galère à coder derrière, est faux. C'est même l'inverse et c'est le but lorsque l'on fait de l'applicatif en bases de données épaisses. Cela simplifie tout, et le code à développer reste/devient minimal au niveau serveur tiers.

Je vous encourage vivement à tout mettre à plat au niveau de votre modèle mais cela implique au préalable de savoir ce que vous souhaitez faire pour le moins.