Tables supplémentaires ou clés étrangères non spécifiques?

Question

Il existe plusieurs types d'objets dans un système et chacun possède sa propre table dans la base de données. Un utilisateur devrait pouvoir commenter n'importe lequel d'entre eux. Comment concevez-vous le (s) tableau (s) de commentaires? Je peux penser à quelques options:

1. Une table commentaires, avec une colonne FK pour chaque type d'objet (ObjectAID, ObjectBID, etc.)
2. Plusieurs commentaires tables, une pour chaque type d'objet (ObjectAComments, ObjectBComments, etc)
3. Un FK (ParentObjectID) générique avec une autre colonne pour indiquer le type ("ObjectA")

Lequel choisiriez-vous? Y a-t-il une meilleure méthode à laquelle je ne pense pas?

Answer 1

@palmsey

Quasiment, mais la variation sur ce modèle que je l'ai vu plus souvent obtient débarrasser de ObjectAID et al. ParentID devient à la fois le PK et le FK à Parents.Que vous obtient quelque chose comme:

• Parents

  • ParentID

• ObjectA

  • ParentID (FK et PK)
  • ColumnFromA NOT NULL

• ObjectB

  • ParentID (FK et PK)
  • ColumnFromB NOT NULL

Comments demeurent les mêmes. Il vous suffit ensuite de limiter la génération d'ID afin de ne pas vous retrouver accidentellement avec une ligne ObjectA et une ligne ObjectB pointant vers la même ligne Parents; la façon la plus simple de le faire est d'utiliser la même séquence (ou quoi que ce soit) que vous utilisez pour Parents pour ObjectA et ObjectB.

Vous voyez aussi beaucoup de schémas avec quelque chose comme:

• Parents
  • ID
  • SubclassDiscriminator
  • ColumnFromA (nullable)
  • ColumnFromB (nullable)

et Comments resteraient inchangés. Mais maintenant vous ne pouvez pas appliquer toutes les contraintes de votre entreprise (les propriétés des sous-classes sont toutes nulles) sans écrire des déclencheurs ou le faire sur une autre couche.

Answer 2

Est-il faisable de concevoir le schéma de telle sorte que les tables commentables (faute d'un meilleur mot) suivent l'un des modèles standards de modélisation d'héritage? Si tel est le cas, vous pouvez placer le point FK de la table de commentaires dans la table parent commune.

Answer 3

@Hank Gay

donc quelque chose comme:

1. ObjectA
   • ObjectAID
   • ParentID
2. ObjectB
   • ObjectBID
   • ParentID
3. Commentaires
   • CommentID
   • ParentID
4. parents
   • ParentID

Answer 4

Faites attention aux clés étrangères génériques qui ne pointent pas exactement sur une table. La performance des requêtes souffre énormément si vous devez diviser la condition where sur un type et pointer vers plusieurs tables différentes. Si vous avez seulement quelques types, et que le nombre de types ne va pas augmenter, il est correct d'avoir des clés étrangères valables séparées pour les différentes tables, mais si vous avez plus de types, il est préférable de créer un modèle de données différent @ suggestion de palmsey).

Answer 5

L'une des choses que j'aime faire est d'avoir des tables séparées reliant la table générique/commune à toutes les tables individualisées.

Ainsi, pour les objets Foo et Bar et commentaires puis Foo & Bar, vous auriez quelque chose comme ceci:

• Foo
  • Foo ID (PK)
• Barre
  • Bar ID (PK)
• Commentaire
  • Commentaire ID (PK)
  • Commentaire Texte
• FooComment
  • Foo ID (PK FK)
  • ID Commentaire (PK FK)
• BarComment
  • Bar ID (PK FK)
  • Commentaire ID (PK FK)

Cette structure:

1. vous permet d'avoir une table Commentaires commune
2. Ne nécessite pas de base de données avec héritage de tables
3. D oesn't pollue les tables Foo et Bar avec des informations relatives Commentaire-
4. vous permet de joindre un commentaire à multiples objets (qui peuvent être desireable)
5. vous permet de connecter d'autres propriétés à la jonction de Foo/Bar et commentaires si désiré.
6. Préserve toujours les relations avec les clés étrangères standard (ie: rapide, simple, fiable)