SQL: une clé étrangère fait référence à la clé primaire dans l'une des tables

Question

Je travaille sur une application qui servira de cadre extensible pour d'autres applications.

L'une des classes fondamentales s'appelle Node, et les nœuds ont un contenu. Les tables SQL ressemblent à ceci:

Noeud TABLE (NodeId int, .... etc)

TABLE NodeContentRelationship (NodeId int, chaîne ContentType, ContentId int)

Il appartiendra aux développeurs d'étendre l'application à la création de leurs propres types de contenu.

Clairement, cela est mauvais du point de vue d'une relation de base de données car il n'est pas possible d'ajouter une relation de clé étrangère à NodeContentRelationship.ContentId, même si il s'agit d'une colonne de clé étrangère.

Cependant, la solution est assez simple et puissante, je suis donc réticent à la changer.

Qu'en penses-tu - suis-je dans un monde de douleur sur la piste?

Answer 1

Pourquoi est-il impossible de définir NoteContentRelationship.ContentId en tant que clé étrangère? Vous pouvez facilement utiliser un modèle d'héritage relationnel avec une table Content représentant une classe de base abstraite et diverses tables AnimalContent , CarContent , etc., dérivés classes.

Answer 2

Faites attention à l’ effet de la plateforme interne .

Si vous essayez de créer un "cadre extensible" qui permette aux développeurs de stocker des données de différents "types de contenu" et de les relier de manière générique, vous constaterez peut-être que d'autres personnes ont déjà résolu this problème .

Answer 3

Cela me semble être une variation de la conception EAV (entité, attribut, valeur).

Les avantages et les inconvénients de la conception EAV ont été abondamment documentés.

Voici une description de l'EAV d'un point de vue sympathique:

http://ycmi.med.yale.edu /nadkarni/Introduction%20to%20EAV%20systems.htm

Et en voici un d'un point de vue hostile:

http: // tonyandrews .blogspot.com / 2004/10 / otlt-and-eav-two-big-design-errors.html

Prenez conscience de l’inconvénient d’EAV avant d’engager des milliers d’heures de travail à lui verser des données. C'est extrêmement séduisant pour les programmeurs, mais cela peut devenir le cauchemar d'un gestionnaire de données.

Answer 4

Si vous souhaitez réellement rendre compte de ces données, vous vous exposez à de nombreuses difficultés. Vous venez de rendre beaucoup plus difficile l'écriture de jointures et autres. Le manque de contraintes est mauvais, mais le travail supplémentaire nécessaire aux requêtes est encore pire (IMHO).

Toutefois, si vous souhaitez que les autres développeurs puissent étendre le système et stocker des données dans la base de données sans pouvoir modifier le schéma de la base de données, vous n'avez peut-être pas le choix. Dans ce cas, la solution consiste à minimiser la quantité stockée de cette manière. Vous pouvez également accélérer légèrement en remplaçant ContentType par un ContentTypeId défini dans une autre table.