J'ai besoin de créer un forum simple (babillard électronique) en tant que projet scolaire. Mais je suis tombé sur un problème. Dans l'image ci-dessus, il y a 2 tables: post et category , qui ont une relation plusieurs-à-plusieurs. J'ai fait une table de bridge, qui stocke la postKey et la categoryKey . Est-ce une mauvaise pratique de créer une clé primaire composite à partir de ces 2 clés, ou j'ai besoin de quelque chose comme postCategoryKey ? Et que dois-je améliorer d'autre?
3 Réponses :
À mon avis, il n'y a pas besoin de PostCategoryKey, car il ne s'agit que d'une table de relations et vous ne pourrez pas y accéder par postCategoryKey. Je créerais le PK en utilisant les 2 autres FK (postKey et categoryKey).
J'espère que cela aide!
Cela dépend, si vous prévoyez plus tard d'ajouter des métadonnées supplémentaires à postCategoryKey dans un tableau séparé, alors cela a du sens.
Dans votre cas, j'irais avec une clé primaire composite et je me débarrasserais de postCategoryKey
Vous devrez rendre postKey et categoryKey non null et créer quand même une contrainte unique sur eux. Cela en fait une clé pour la table, que vous l'appeliez ou non la "clé primaire".
Il existe donc trois options:
NOT NULL et la contrainte d'unicité. postCategoryKey et faites-en la clé primaire. La décision n'a pas vraiment d'importance. Certaines entreprises ont une convention de style de base de données. Dans ce cas, c'est facile; suivez simplement les règles de l'entreprise. Certaines personnes souhaitent que chaque table ait une clé primaire à une seule colonne. Si tel est le cas, ajoutez cette colonne PK. Certaines personnes veulent que les tables de pont aient une clé primaire composite pour montrer immédiatement ce qui identifie une ligne. Ma préférence personnelle est la dernière, mais n'importe quelle méthode est aussi bonne que l'autre en fait. Restez cohérent dans votre base de données.