Forum Programmation.SQL Cherche conseils d'architecture SQLite

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
0
17
sept.
2020

Bien l'bonjour !

Je cherche à creer dans une bdd SQLite la liste des cartes d'un jeu de société.
Parmis la liste complète des caractéristiques possibles (une vingtaine en tout peut-être), chaque carte peut en posséder : aucune, une ou plusieurs.
Je cherche le meilleur moyen pour construire une ou des tables pour stocker tout ça.

Est-ce qu'il vaut mieux :

avoir une table pour chaque carte, une table pour chaque caractéristique, et une table de lien avec un enregistrement pour chaque caractéristique de chaque carte,

ou

tout regrouper dans la table carte, avec un champs booléen pour chaque caractéristique ?

Merci pour vos conseils éclairés.

Edit pour plus de précision :
Le genre de requête qui va être formulée sur cette base va être "donne moi la liste des cartes possédant les caractéristiques A et B, ou C, mais pas D ni E"

  • # Modélisation

    Posté par  . Évalué à 4 (+2/-0). Dernière modification le 17/09/20 à 17:03.

    Salut,

    Je peux me tromper, mais je pense qu'il ne s'agit simplement que d'un problème de modélisation.

    Moi, je ferais trois tables :

    • une jeu qui référence les cartes,
    • une cartes qui référence les attributs,
    • une attributs qui référence bin… les attributs :)
  • # Trois

    Posté par  (site Web personnel) . Évalué à 2 (+0/-0).

    Les caractéristiques existent en tant que tel (éventuellement avec une série d'attributs) → une table pour les caractéristiques, avec une clé.

    Une carte peut posséder 0 à n caractéristiques → une table liaison clé de carte — clé de caractéristiques.

    Et une table des cartes (vu qu'on peut avoir une carte sans caractéristique… il faut bien savoir qu'elle existe), avec une clé. Dans laquelle tu peux ajouter éventuellement des infos sur la carte elle-même (ex. nb d'occurrences de la carte)

    Même résultat que kaos.

    Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

  • # Merci

    Posté par  . Évalué à 1 (+0/-0).

    Pour vos réponses. Ça correspond à mon premier cas de figure, c'est comme ça qu'elle existe actuellement. Je me demandais juste si ça n'était pas plus efficace de faire autrement.

    • [^] # Re: Merci

      Posté par  . Évalué à 2 (+0/-0).

      Salut,

      Pas de soucis.

      Tant que tu n'as pas de spacio/temporel, modéliser reste généralement assez simple sur une idée bien formulée ;)

      Par contre, il te faudra à minima faire des select "imbriqués" avec un modèle comme proposé, donc là, si tu n'en a jamais fait, ça picote un peu. Mais c'est pas infaisable !

      Bon courage ;)

  • # Tout dépend !

    Posté par  (site Web personnel) . Évalué à 6 (+4/-0).

    Hello,

    J'apporte ma petite pierre à l'édifice. Tout dépend de l'usage qui va en être fait.

    Si tu ne fais à termes que des SELECT avec le type de requête que tu nous as présentée, et que les attributs sont fixes et n'évolueront pas, alors une seule table est un choix pertinent du point de vue des performances (comme il s'agit de booléens pour les attributs, il est possible d'avoir des recherches à base d'opérateur booléens AND, XOR, etc.).

    Si le stockage est un facteur important, l'espace sera bien moindre ici qu'avec une modélisation 3 tables, sauf à avoir des milliers d'attributs. et juste quelques attributs par carte.

    Si maintenant les requêtes sont un peu plus dynamique (tel attribut mais pas tel attribut, mais je ne sais pas à l'avance les attributs concernés, ça va dépendre du contexte), alors la modélisation en 3 tables est la mieux adaptée.

    Comme toujours, il n'y a pas LA réponse, il y a plusieurs possibilités, chacune avec des avantages et des inconvénients.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.