Système de gestion d'unités

[Arkhanz]

Effectivement, je n'avais pas mesuré tant de points négatifs, je te rejoins donc Xenos. Toutefois je me demande si un stockage aussi important en terme d'entrées n'impacte pas le temps de chargement d'une page. Une recherche dans 10.000.000 de lignes peut augmenter significativement le temps de chargement à moins d'avoir placé index et clés aux bons endroits et en appliquant plusieurs astuces d'optimisation par rapport aux requêtes en elles-même - du moins sur un hébergement mutualisé modeste (qui plus est souvent très limité en mémoire). Mais dans la théorie je te rejoins complètement, n'ayant pas de chiffres ou une expérience pouvant appuyer mon doute.

[Xenos]

à moins d'avoir placé index et clés aux bons endroits

MySQL gèrera alors très bien la chose

La meilleure méthode est d'utiliser la structure la plus propre en premier, de tester, et si vraiment c'est lent/pas réalisable, changer pour une structure moins élégante. Mais SQL n'aura peur qu'à partir de tables de plusieurs giga, pas "quelques" millions d'entrées seulement ^^

C'est PHP qui peut ralentir après... construire 10.000 objets, un par unité, sera un peu pesant. Mais là encore, c'est à tester, avant de se lancer dans le dégueux...!

[Sliverik]

Salut!

Je gere egalement des unites regroupees dans des armees dans mon jeu, et je me demande pourquoi tu ne mets pas simplement une colonne "id_proprietaire" dans la table unite, ou tu indiques simplement a quel joueur elle appartient, au lieu de passer par une table a part.
Sinon, si tu veux creer une table "possede", ce que je ferais, c'est d'identifier chaque type d'element de ton jeu par un identifiant (unite: 1, ville: 2, ...) et du coup, la table ressemblerait a
id_possede id_joueur id_categorie id_element
i 1 1 56
i+1 1 2 9

cette table indiquerait donc que le joueur 1 possede l'unite 56 et la ville 9.

[Xenos]

Je ne crois pas que ce genre de structure permette d'utiliser les clefs étrangères (aka, l'outil du SGDB qui permet d'assurer que la ville 9 existe bien, et que l'unité 56 existe également). Suivant si les clefs sont utilisées, cela peut poser problème.

[Sliverik]

Ouais, j'avais pas pense a ca.
Mais alors, ma premiere solution fonctionne quand meme, non?
Indiquer la propriete a un joueur dans l'entree de l'unite directement, pour gagner une table.

[Xenos]

Si la relation est de type 1-N (1 unité ne peut être possédée que par 1 joueur), oui (l'id du joueur dans la table de l'objet me semble correcte). De même dans le cas 1-1 (1 joueur ne peut posséder qu'1 unité).
Si la relation est de type N-N (N joueurs peuvent posséder la même unité, et chaque joueur peut posséder N unités), seule une table séparée est utilisable.

Mais la table séparée, bien que plus lourde, permet une meilleure évolution. Tout dépend du chemin que devra prendre le projet.

[Sehsyha]

Oui ta solution fonctionne mais ne garantit pas l'intégrité des données si il n'y a pas de clés étrangères à mon avis. Imagine que tu modifie une unité en la supprimant et en la recréant, si son id change, toutes les personnes ayant cette unité ne l'auront plus. Ce sera donc difficile de garantir toute l'intégrité si jamais le projet grandit.

[Harparine]

Salut,
Supprimer et recréer une unité n'est pas la modifier. Une modification devrait s'effectuer sur une ligne existante en conservant son ID.
S'il est nécessaire de supprimer une unité pour la modifier, c'est qu'il y a une erreur de conception quelque part. L'intégrité des données devrait normalement être respectée.
Personnellement, j'utiliserais le système suivant :

Table joueurs
id, nom, etc.

Table unites_modeles
id, nom, caracteristique1, caracteristique2, etc.

Table armees
id, joueur_id, nom, etc.

Table unites
id, armee_id, unite_modele_id, caracteristique1, caracteristique2, etc.

De cette manière, l'appartenance à un joueur passe par l'appartenance à une armée et la table de "jointure" unites permet de stocker les caractéristiques de chaque instance d'unite_modele (car ces caractéristiques évolueront au cours de la partie : gain d'xp, perte de moral, points de vie, etc.).
C'est une proposition à l'arrache mais on pourrait même envisager d'ajouter une table liée à l'unité pour y joindre des personnages spéciaux (capitaine, médecin de campagne, héros, etc.), déplaçables d'une unité à l'autre et permettant de modifier les caractéristiques de l'unité.

Je pense que la multiplication du nombre de tables n'est pas gênante lorsqu'elle est associée à un bon système de cache permettant un accès rapide à l'objet PHP.
++