Meilleure pratique pour les relations partagées entre plusieurs tables

Question

Je continue de rencontrer ce problème de conception et je ne suis pas satisfait de ma solution jusqu'à présent. Le problème est:

J'ai deux ou plusieurs entités, comme People et Dogs, et ils ont tous deux une relation avec une table Notes, qui stocke un champ de message et quelques méta-données sur le message comme peut-être l'auteur.

1) La première option consiste à ne pas appliquer la clé étrangère. De cette façon, je peux stocker le FK comme PeopleId ou DogId (peu importe ce que c'est) dans le même champ FK générique comme fkId. Ensuite, je stocke la tableId dans une autre colonne - on peut espérer obtenir l'ID de la table à partir des métadonnées RDMS, mais vous pouvez également avoir un hack sale et faire explicitement une table complète de tables que vous auriez à mettre à jour manuellement . C'est vraiment bâclé et je le mentionne juste pour l'exhaustivité.

2) Cloner la table Notes pour chaque table qui en a besoin, comme PeopleNotes, DogNotes, CatNotes, etc. Cela crée un problème majeur de normalisation.

Qu'ont fait les autres personnes dans de telles situations?

Answer 1

Si ce sont vos tables « modèles »:

dog Table: 
id | name | ... 
1 | Rex 
2 | Fido 

people Table: 
id | name | ... 
1 | Bob 
2 | Alice 

notes Table: 
id | text | ... 
1 | A nice dog. 
2 | A bad dog. 
3 | A nice person. 

Vous pouvez avoir les relations conservées dans des tables séparées:

dog_note Table: 
dog_id | note_id 
1  | 1 
2  | 2 

note_people Table: 
person_id | note_id 
1   | 3 
2   | 3 

Je colle habituellement avec la convention d'utiliser l'ordre alphabétique de mon modèles pour nommer les tables de relations.

Answer 2

Je préfère l'idée de stocker le propriétaire de la note dans deux colonnes, une pour l'ID, et une pour la classe/table.

Answer 3

Que diriez-vous de deux nouvelles tables - Dog2Notes et People2Notes? Les chiens, les personnes et les notes sont tous des entiers avec des clés liées les unes aux autres. Les chiens et les personnes peuvent avoir plus d'une note et les notes peuvent être partagées.

Si Chiens et Personnes ne peuvent avoir qu'une seule note chacun, alors ajoutez un NOteID à chacune de ces tables?

Answer 4

cela dépend vraiment de la façon dont vous interrogez vos données, mais que diriez-vous quelque chose comme ça, suppose qu'il ya plusieurs notes par personne/chien:

PeopleTable

PeopleID 
NoteID 
..... 

DogTable

DogID 
NoteID 
... 

RemarqueTable

NoteID 

NoteDetailTable

NoteDetailID 
NoteID 
NoteText 
... 

Answer 5

Ne serait-pas une meilleure solution que celle proposée actuellement d'avoir une table identifiant maître?

dog Table: 
id | name | masterId 
1 | Rex | 1 
2 | Fido | 4 

people Table: 
id | name | masterId 
1 | Bob | 2 
2 | Alice| 3 

masterId 
id 
1 
2 
3 
4 

notes 
id | note  | masterId 
1 | "Hi"  | 3 
2 | "Good day" | 2 

Cela rendrait l'évolutivité plus facile parce que si vous avez besoin d'ajouter un nouveau type d'entité (par exemple, chat), vous auriez pas besoin d'ajouter une autre table (cat_note), il est particulièrement utile si vous ajoutez une nouvelle note tapez (par exemple livre) parce que vous auriez besoin d'ajouter de nouvelles tables pour tous vos types d'entités (person_book, dog_book, etc.).Enfin, vous pouvez directement associer une table d'entités à la table de notes. Le seul «problème» serait que vous ayez besoin d'une procédure qui ajouterait automatiquement un nouvel enregistrement à la table masterId lorsqu'un nouvel enregistrement serait ajouté à une table d'entités et l'associerait à la nouvelle entrée.

P.S. Je sais que cette réponse est comme neuf mois après le fait. Juste arrivé à ce sujet tout en faisant d'autres recherches et pensé que je mets mes propres deux cents po.