Elles sont énormes tes tables ! ^^ 5 tables avec des dizaines de champs, déjà, ça semble douteux.
Il y a un assez bon tuto sur le forum, ici, qui te permettra de savoir si ta base suit un minimum de règles de bonne construction. En pratique on peut être amené à transgresser ces règles pour avoir quelques raccourcis ou de meilleures perfs, mais il vaut mieux construire sa base en les suivant autant que possible.
Je ne crois pas qu'il y ait de tuto qui explique comment construire sa base pour qu'elle soit normalisée dès le départ, j'en ferais peut-être un (c'est ce que j'apprend en ce moment à l'école, autant que ça serve).
Et déjà quelques remarques sur ta base pour appuyer ou compléter celles de Zamentur :
- les parcelle1, parcelle2... parcelle X sont à bannir absolument ! Et si un jour tu décides de faire évoluer ton jeu en faisant sauter la limite au nombre de parcelles ? Et si tu as 5000 joueurs qui n'ont qu'une parcelle, tu va garder 5000*(X-1) valeurs "NULL" dans ta table ?
- "Troupes_attaquantes", qu'est-ce que c'est ? une liste ? Les champs d'une bdd ne peuvent pas contenir de liste. Un id ? de quoi ?
- dans le même genre, pose toi la question "quel type de donnée est-ce ?" Dans une bdd on peut avoir 3 grands types de données : des nombres (entiers ou réels), du texte (plus ou moins long) et des dates (et encore, ce dernier type on pourrait s'en passer).
- ta base évoluera mal, parce que le nom de tes champs, en eux-mêmes, contiennent trop d'information. Transforme "mine, scierie, tresorier" (qui déjà devraient s'appeler plutôt "niveau_mine, niveau_scierie, niveau_tresorier"...) en une table Bâtiments:"id joueur, type_batiment, niveau_batiment". Pareil pour les ressources, la quantité de troupes, etc. Avantage : tu peux ajouter de nouveaux types de bâtiments, ressources, troupes... sans toucher à la structure de ta bdd !
- les noms de tes tables et de tes champs pourraient être plus précis et plus explicites : cf. ma remarque sur "mine, scierie, tresorier" plus haut, mais aussi la table "armées" qui pourrait s'appeler "types d'unités", "joueur attaquant/attaqué" n'est pas très clair sur le type de données enregistré : "id attaquant/attaqué" ou même "id joueur attaquant/attaqué" serait plus propre. Il n'existe malheureusement pas de méthode toute faite pour trouver les bons noms...
- ne stocke pas d'informations que tu peux recalculer (par exemple le COUNT pour le nombre de parcelles), sauf si le calcul ralentit vraiment ta bdd (dans ce cas crée-toi une petite table à part).
- chaque table doit contenir une clé (ou une combinaison de clés). Cette clé est importante, elle te permet de distinguer une entrée de toutes les autres. Indique-la (en la soulignant par exemple). Je ne vois pas quelle est la clé de la table Mine, Scierie, Trésorier.
Il y a un assez bon tuto sur le forum, ici, qui te permettra de savoir si ta base suit un minimum de règles de bonne construction. En pratique on peut être amené à transgresser ces règles pour avoir quelques raccourcis ou de meilleures perfs, mais il vaut mieux construire sa base en les suivant autant que possible.
Je ne crois pas qu'il y ait de tuto qui explique comment construire sa base pour qu'elle soit normalisée dès le départ, j'en ferais peut-être un (c'est ce que j'apprend en ce moment à l'école, autant que ça serve).
Et déjà quelques remarques sur ta base pour appuyer ou compléter celles de Zamentur :
- les parcelle1, parcelle2... parcelle X sont à bannir absolument ! Et si un jour tu décides de faire évoluer ton jeu en faisant sauter la limite au nombre de parcelles ? Et si tu as 5000 joueurs qui n'ont qu'une parcelle, tu va garder 5000*(X-1) valeurs "NULL" dans ta table ?
- "Troupes_attaquantes", qu'est-ce que c'est ? une liste ? Les champs d'une bdd ne peuvent pas contenir de liste. Un id ? de quoi ?
- dans le même genre, pose toi la question "quel type de donnée est-ce ?" Dans une bdd on peut avoir 3 grands types de données : des nombres (entiers ou réels), du texte (plus ou moins long) et des dates (et encore, ce dernier type on pourrait s'en passer).
- ta base évoluera mal, parce que le nom de tes champs, en eux-mêmes, contiennent trop d'information. Transforme "mine, scierie, tresorier" (qui déjà devraient s'appeler plutôt "niveau_mine, niveau_scierie, niveau_tresorier"...) en une table Bâtiments:"id joueur, type_batiment, niveau_batiment". Pareil pour les ressources, la quantité de troupes, etc. Avantage : tu peux ajouter de nouveaux types de bâtiments, ressources, troupes... sans toucher à la structure de ta bdd !
- les noms de tes tables et de tes champs pourraient être plus précis et plus explicites : cf. ma remarque sur "mine, scierie, tresorier" plus haut, mais aussi la table "armées" qui pourrait s'appeler "types d'unités", "joueur attaquant/attaqué" n'est pas très clair sur le type de données enregistré : "id attaquant/attaqué" ou même "id joueur attaquant/attaqué" serait plus propre. Il n'existe malheureusement pas de méthode toute faite pour trouver les bons noms...
- ne stocke pas d'informations que tu peux recalculer (par exemple le COUNT pour le nombre de parcelles), sauf si le calcul ralentit vraiment ta bdd (dans ce cas crée-toi une petite table à part).
- chaque table doit contenir une clé (ou une combinaison de clés). Cette clé est importante, elle te permet de distinguer une entrée de toutes les autres. Indique-la (en la soulignant par exemple). Je ne vois pas quelle est la clé de la table Mine, Scierie, Trésorier.