Gestion d'un jeu vidéo
Bonjour,
J'ai actuellement un site qui permet de simuler certains équipements utilisés dans un jeu vidéo pour avoir une idée d'optimisation de son personnage dans le jeu. Le site subit une très forte affluence, et j'ai tout appris par moi-même (HTML, PHP, CSS, Javascript / Jquery). J'ai une formation informatique généraliste à la base mais je n'ai jamais eu l'occasion ou l'expérience de la mise en place de base de données complexes. Aujourd'hui avec ce site, j'aimerai soumettre mon modèle de données et avoir vos avis d'experts sur les opportunités pour l'améliorer. Je suis parti d'un modèle assez bancale, pas normalisé, qui avec l'affluence actuelle du site (1M de visites par mois) me pose soucis. Je vous joints le MLD que j'ai essayé d'améliorer au maximum mais mes cours de BD remontent à loin et j'avoue être assez rouillé sur le sujet
Principes de base du modèle:
- La table membre représente les membres inscrits au site
- La table perso représente les personnages gérés par les membres en jeu
- La table item représente les objets qui peuvent être équipés sur un personnage
- La table pano représente les panoplies qui sont en fait un ensemble d'items qui, une fois réunis, donnent des effets particuliers
Règles sur les membres
- RG01 : Un membre peut avoir de 0 à 8 personnages
- RG02 : Un membre peut avoir 0 à N événements mémorisés. Exemple d'événement: le membre X a passé les 100 visites sur le site le jour J. (table dof_membre_log)
- RG03 : Un membre peut si il le souhaite compléter son profil avec des informations facultatives comme une présentation, sa date de naissance etc. Ceci n'est pas obligatoire. (table dof_membre_profil)
- RG04 : On a besoin de connaître le nombre et les noms des membres connectés sur le site. Un membre est considéré comme étant connecté si sa dernière activité sur le site est inférieure à 3 minutes. (table dof_online)
- RG05 : Un membre peut être soit banni, soit visiteur, soit inscrit, soit modérateur, soit administrateur (attribut forum_rang de la table dof_membre)
Règles sur les personnages
- RG06 : Un personnage appartient à un et un seul membre
- RG07 : Un personnage possède de 1 à 3 équipements exactement
- RG08 : Un personnage peut avoir activé de 0 à N sorts pour se booster (table dof_perso_boost)
- RG09 : Un personnage peut exercer de 0 à 6 métiers (table dof_perso_metier)
- RG10 : Un personnage dispose d'exactement 12 caractéristiques comme son intelligence, son agilité, sa force, etc qui peuvent prendre des valeurs de 0 à 2000 (table dof_perso_carac)
Règles sur les équipements
- RG11 : Un équipement appartient à un et un seul personnage
- RG12 : Un équipement est composé de 0 à 16 items
- RG13 : Chaque item équipé sur un personnage est identifiable par sa position dans l'équipement de ce personnage, par exemple: arme, chapeau, cape, gant gauche, gant droit, etc... (attribut pos de la table dof_perso_item)
- RG14 : L'équipement d'un personnage peut être nommé. Ceci n'est pas obligatoire. (table dof_perso_nom)
- RG15 : Chaque item équipé sur un personnage peut avoir des effets particuliers différent de ceux de l'item d'origine, si le personnage a modifié l'item grâce à ses métiers de forgeron. Un membre lorsqu'il simule l'équipement de son personnage a donc le choix entre laisser les effets d'origine d'un item ou modifier les effets. (les effets modifiés sont stockés dans la table dof_perso_fm)
Régles sur les items
- RG16 : Un item peut être soit un "vêtement" (cape, chapeau, ceinture, etc), soit une arme (épée, hache, marteau, etc) (attribut category de la table dof_item)
- RG17 : Un item donne 0 à N effets de type bonus si il s'agit d'un vêtement (exemple: +20 en force, -5 en agilité, etc)
- RG18 : Un item donne 0 à N effets de type bonus et/ou 1 à N effets de type Dégât si il s'agit d'une arme. (attribut cat de la table dof_item_effet)
- RG19 : Un effet de type bonus ne peut être présent qu'une seule fois sur un item
- RG20 : Un effet de type degât peut être présent plusieurs fois sur le même item
- RG21 : Un item peut avoir de 0 à N pré-requis pour être porté (exemple: force > 300, quête = 'xyz' terminée, etc)
- RG22 : Les pré-requis d'un item peuvent être cumulables ou non
Exemple 1: (force > 300 ET intelligence < 100)
Exemple 2: (force > 300 ET intelligence < 100) OU (agilité > 100)
Cela est géré par l'attribut groupe de la table dof_item_cond. Ainsi l'exemple 2 sera modélisé par:
- groupe 1 : (force > 300 OU agilité < 100)
- groupe 2 : (intelligence < 100 OU agilité < 100)- RG23 : Un item peut nécessiter de 0 à 8 ingrédients exactement pour être fabriqué (0 signifie que cet item ne peut pas être fabriqué, mais juste gagné lors de concours, quêtes, etc)
- RG24 : Un item peut être soit fabriqué, soit gagné lors de concours, soit gagné en combattant des ennemis dans le jeu. (attribut fabrication de la table dof_item)
- RG25 : Une arme à 8 caractéristiques exactement comme son coût en utilisation, si il nécessite 1 ou 2 mains pour être portée, etc (table dof_arme_carac)
- RG26 : Un item qui n'est pas une arme n'a pas de caractéristiques
- RG27 : Un item peut faire parti de 0 ou 1 panoplie
- RG28 : Un item peut être modifié par 0 ou N modérateurs. Seul la dernière modification (auteur + date) est mémorisée en base (table dof_item_modif)
Règles sur les panoplies
- RG29 : Une panoplie est composée de 2 à 8 items
- RG30 : Une panoplie octroie différents effets, selon le nombre d'items de cette panoplie équipés (de 1 à N effets). Par exemple une panoplie comportant 5 items donnera plus de bonus si on porte les 5 items, moins de bonus si on en porte que 4, etc. Les effets apportés par une panoplie sont donc dépendants de la panoplie et du nombre d'items portés pour cette panoplie (attribut nb de la table dof_pano_effet)
Voilà je crois avoir à peu près tout listé
Remarques additionnelles et auto-critique du modèle actuel
Gestion des équipements
- RA1 : Un personnage ayant exactement 3 équipements, je n'ai pas créé d'entité équipement, j'ai en fait dupliqué l'ensemble des tables utiles pour identifier un équipement. J'ai donc une table dof_perso_item1, une table dof_perso_item2, une table dof_perso_item3, idem pour dof_perso_nom, dof_perso_boost, dof_perso_carac et dof_perso_fm. Cela pour avoir des tables moins grosses à gérer puisqu'un membre ne peut consulter en même temps qu'un seul équipement, et qu'une table comme dof_perso_item1 contient déjà 700.000 lignes à elle seule. Je ne sais pas si c'est un bon choix d'avoir procédé comme cela. Je n'ai pas représenté cette duplication des tables dans le schéma joint pour plus de lisibilité.
- RA2 : Je n'ai pas créé de table position pour lister les différents emplacements que peut occuper un item sur un personnage (arme, chapeau, cape, etc). Au lieu de cela j'ai directement mis en clé primaire la position dans les tables dof_perso_item et dof_perso_fm (attribut pos) car ce sont des CHAR(2) donc je trouvais que ça ne valait pas forcément le coup de créer une table des positions avec clés étrangères sur les tables dof_perso_items et dof_perso_fm sur la position (sachant que les positions possibles pour équiper un item sur un personnage sont au nombre de 16 et n'évolueront jamais). Je ne sais pas encore une fois si c'est le meilleur choix.
- RA3 : La table dof_perso_fm, qui contient les effets modifiés par un membre pour un item, différents des effets d'origine, n'est pas normalisée. L'attribut effets contient directement la liste des effets modifiés ainsi que leur valeur sous la forme: effet1=20&effet2=10&effet3=0 etc. J'ai opté pour ce choix car la table dof_perso_fm contient déjà 700.000 lignes, donc sachant qu'un item peut avoir jusqu'à environ 20 effets différents, normaliser cette table reviendrait à multiplier le nombre de lignes par 20 (maximum), je dirai en moyenne par 10, ce qui fait 7M de lignes. Ça commence à faire beaucoup sans compter le taille occupée en base car en normalisant je vais devoir dupliquer la clé primaire (perso, membre, pos) + ajouter un attribut "valeur". Par contre je peux remplacer l'attribut "effets" par "effet" en CHAR(2) donc je gagne sur cet attribut. Que me conseillez-vous ?
- RA4 : Même remarque qu'au dessus pour la table dof_perso_boost
Gestion des items
- RA5 : A cause de la RG20, je n'ai pas pu inclure dans la clé composite primaire l'attribut effet de la table dof_item_effet. J'ai dû ajouter l'attribut seq qui est un entier auto-incrémenté pour chaque effet d'un item. Cela n'arrive pas pour les panoplies puisqu'elles n'ont pas d'effets de type Dégât. La table dof_pano a donc bien l'attribut effet qui fait parti de la clé composite primaire.
- RA6 : La catégorie de l'item, j'imagine, mériterait d'être mise dans une table dédiée en gardant juste un attribut en clé étrangère "category" dans la table dof_item
- RA7 : J'ai laissé une clé primaire naturelle pour la table dof_effet - code de l'effet en VARCHAR(4) - et les tables liées aux effets (dof_item_effet, dof_pano_effet) au lieu de créer un attribut de type INT auto-incrémenté. Même remarque pour la table dof_item_cond. Est-il recommandé de passer le code de l'effet en clé alternative avec ajout d'une clé primaire non-naturelle de type INT ?
- RA8 : dof_arme_carac n'est pas normalisée. Au lieu de créer autant d'attributs dans cette table qu'il y a de caractéristiques pour une arme, j'aurai pu créer cette table : DOF_ARME_CARAC(item#, carac#, valeur) + la table DOF_CARAC(carac, description). Mon problème c'est que les caractéristiques d'une arme sont parfois des ENTIER, parfois des VARCHAR, parfois un BOOLEEN, etc. Donc je ne sais pas trop comment gérer efficacement mon attribut valeur.
Gestion des personnages
- RA9 : Je ne sais pas si il vaut mieux garder une identification relative pour les tables perso (membre, perso) avec perso = INT entre 1 et 8 (car un membre peut avoir au maximum 8 persos) ou passer en identification absolue sur le perso. Je pensais par exemple définir l'identifiant du perso en INT qui serait égal à l'identifiant du membre concaténé avec le numéro de perso de 1 à 8. Ainsi le personnage numéro 6 du membre numéro 478 aura comme identifiant 4786, le personnage numéro 3 aura comme identifiant 4783, etc. Je pense que c'est un peu (beaucoup) tordu comme approche ^_^ Ou sinon mettre un simple INT auto-incrémenté comme identifiant du personnage.
Gestion des panoplies
- RA10 : L'attribut nb_items d'une panoplie représente le nombre d'items qui compose une panoplie. Cette information est redondante car on peut la retrouver en comptant le nombre d'items liés à une panoplie depuis dof_item. Seulement j'ai pensé qu'il serait lourd de faire un COUNT à chaque fois que j'ai besoin d'afficher le nombre d'items qui composent une panoplie.
Merci par avance à ceux qui auront eu le courage de me lire, et pour m'aider à améliorer ce modèle de données
Répondre avec citation
Partager