N'utilise pas des noms (textes) pour faire des références entre BDD et code serveur (PHP, ruby, python, java...), préfère les identifiants numériques (id_type_unite au lieu d'un nom_unite). Déjà, il y a moins de raison d'en changer, ensuite tu y gagneras en place dans la BDD et en perfs, enfin tu pourras placer des contraintes dessus plus facilement.
En cas de changement de nom, seul le nom affiché (stocké dans un PHP par exemple, ou dans un XML comme j'aime à le faire) sera impacté: l'identifiant numérique n'aura pas de raison d'être modifié.
La classe abstraite (UnitéArtillerie) peut être utile simplement pour regrouper les unités par type, même si leurs caractéristiques sont les mêmes d'un type à l'autre. A toi de voir
Tu peux aussi choisir une approche à interface, et créer une interface par "possibilité" (TireDesObus, TireDesBalles, TirDeZone, PossedeFumigenes,...) puis implémenter les interfaces nécessaires dans la classe de l'unité, même si ces interfaces sont vides, c'est juste un indice sur les capacités de l'unité. Cela servira peut-être plus tard, soit en y ajoutant du code, soit en testant $unite instanceof TirDesObus pour savoir quels textes d'aide afficher.
Dernier élément: les clefs primaires peuvent porter sur plusieurs colonnes, je ne sais pas si "id_possede" est vraiment utile. Si tu ne l'utilises pas, tu peux t'en passer, et le remplacer par une PRIMARY KEY (id_joueur, id_unite) (attention à l'ordre des colonnes: l'index n'est utilisé que si la 1ere colonne est utilisée dans la clause WHERE, pour simplifier; donc un WHERE id_unite=11 n'utilisera pas la clef, alors que WHERE id_joueur=42 l'utilisera, de même que WHERE id_joueur=42 AND id_unite=11).
Je ne pense pas qu'externaliser les caractéristiques dans une table à part soit nécessaire, ou utile, étant donné qu'ici, l'unité n'est composée que de ces caractéristiques. Cela va rajouter une couche pour par grand chose. Ce serait pertinent si la table "Unité" pouvait être modifiée soit pour changer les caractéristiques, soit pour changer autre chose, mais là, n'ayant pas de "autre chose", cela me semble superflu de créer une jointure de plus.
En cas de changement de nom, seul le nom affiché (stocké dans un PHP par exemple, ou dans un XML comme j'aime à le faire) sera impacté: l'identifiant numérique n'aura pas de raison d'être modifié.
La classe abstraite (UnitéArtillerie) peut être utile simplement pour regrouper les unités par type, même si leurs caractéristiques sont les mêmes d'un type à l'autre. A toi de voir
Tu peux aussi choisir une approche à interface, et créer une interface par "possibilité" (TireDesObus, TireDesBalles, TirDeZone, PossedeFumigenes,...) puis implémenter les interfaces nécessaires dans la classe de l'unité, même si ces interfaces sont vides, c'est juste un indice sur les capacités de l'unité. Cela servira peut-être plus tard, soit en y ajoutant du code, soit en testant $unite instanceof TirDesObus pour savoir quels textes d'aide afficher.Dernier élément: les clefs primaires peuvent porter sur plusieurs colonnes, je ne sais pas si "id_possede" est vraiment utile. Si tu ne l'utilises pas, tu peux t'en passer, et le remplacer par une PRIMARY KEY (id_joueur, id_unite) (attention à l'ordre des colonnes: l'index n'est utilisé que si la 1ere colonne est utilisée dans la clause WHERE, pour simplifier; donc un WHERE id_unite=11 n'utilisera pas la clef, alors que WHERE id_joueur=42 l'utilisera, de même que WHERE id_joueur=42 AND id_unite=11).
Je ne pense pas qu'externaliser les caractéristiques dans une table à part soit nécessaire, ou utile, étant donné qu'ici, l'unité n'est composée que de ces caractéristiques. Cela va rajouter une couche pour par grand chose. Ce serait pertinent si la table "Unité" pouvait être modifiée soit pour changer les caractéristiques, soit pour changer autre chose, mais là, n'ayant pas de "autre chose", cela me semble superflu de créer une jointure de plus.