Architecture Base de donnée

[Sephi-Chan]

Du coup, la mise en commun des champs, c'est assez étrange niveau modélisation, mais pourquoi pas.

[Globe]

Si tes personnages récupèrent leur position de la table items, quel intérêt d'avoir l'id d'une planète ou d'une ville dans la table personnages ?

[ToraTora]

Si tes personnages récupèrent leur position de la table items, quel intérêt d'avoir l'id d'une planète ou d'une ville dans la table personnages ?

Parce que mon personnage peut se trouver sur une planète ou dans un ville.

[Globe]

Et tes objets non ?

Edit: Pourquoi ne pas stocker ces informations dans la table items ?

[ToraTora]

Oui mes objets aussi.
Effectivement, je pourrais stocker ça dans Items aussi.

J'aurais donc ça :

positions (items):
id, x, y, z, planete_id, ville_id
planetes:
item_id, nom, description
personnages:
item_id, nom, description, [caractéristiques...]
vaisseaux:
item_id, nom, description, [caractéristiques...]
objets:
item_id, nom, description, [caractéristiques...]

[Globe]

Ça me paraît plus logique que de passer par deux tables pour gérer la position, sinon à chaque mouvement ça te ferait deux mises à jours à faire et à chaque affichage deux requêtes pour récupérer la position.

Sans plus de détails ça me paraît viable, mais je suis loin d'être compétent dans le domaine donc je laisserais les autres s'exprimer.

[niahoo]

il te faut différencier les types d'objets et les objets possédés

dans vaisseaux()
id, nom, description, [caractéristiques]

exemple
42, falcon, "super vaisseau de combat", [...

et dans vaisseaux_joueurs()
id, id_joueur, id_vaisseau, x, y, z


et les coordonnées doivent te permettre de retrouver la planète et la ville.

[Globe]

Tout dépend de comment son jeu fonctionne non ? Les coordonnées permettent de trouver la planète, mais ça se trouve il met juste une liste des villes présentes sur la planète, sans carte sans rien, elles posséderaient donc toutes les mêmes coordonnées.

Sinon je pensais à la même chose concernant ses tables, mais après tout dépend de si il existe des types prédéfinis de vaisseaux... Si il n'utilise pas de classes génériques pour les vaisseaux et que chacun est totalement personnalisé, le système est pas nécessaire, enfin je pense non ?

[niahoo]

tu as en partie raison, mais quand tu parles de classes je me méfie, le modèle conceptuel des données n'est pas dépendante de l'implémentation que tu vas en faire par la suite.

il ne me semble pas nécessaire de stocker les caractéristiques d'un vaisseau et l'id du joueur le possédant dans la même table. les caractéristiques/nom/description sont probablement génériques à tous les vaisseaux ayant le même id, donc dans une table items ou vaisseaux, quant à l'association joueur/vaisseau elle doit se faire à part. Si le joueur apporte des bonus à son vaisseau ça peut se mettre dans une table modélisant cette association.

mais en effet on n'a pas assez d'éléments pour vraiment savoir de quoi il retourne.

perso je passe toujours par MERISE ou une simili-merise pour créer un mcd, ça permet de bien poser ses idées et la modélisation des tables se fait ensuite naturellement, ne demandant de réflexion que pour des cas particuliers (optimisation des perfs, clés primaires représentant des associations, etc.)

[Globe]

Oui d'accord c'est ce que je me disais, personnellement je passe par la bonne vieille méthode, en utilisant des schémas et croquis papiers, en planification j'en ai déjà eu des centaines et des centaines (de croquis) donc c'est vrai qu'un logiciel peut faciliter les choses. Après c'est vrai que je code en procédural (pour lequel il me semble beaucoup plus simple de créer ses tables au fur et à mesure que le projet avance) donc c'était pour m'imprégner du projet et comprendre comme j'allais faire les choses plutôt que véritablement organiser.