SQL: una chiave esterna fa riferimento alla chiave primaria in una delle diverse tabelle

Question

Sto lavorando a un'applicazione che verrà utilizzata come framework estensibile per altre applicazioni.

Una delle classi fondamentali si chiama Nodo e i nodi hanno contenuto. Le tabelle SQL sono simili alle seguenti:

Nodo TABELLA (NodeId int, .... etc)

TABELLA NodeContentRelationship (NodeId int, stringa ContentType, ContentId int)

Spetterà agli sviluppatori estendere l'applicazione per creare i propri tipi di contenuto.

Chiaramente questo è un male dal punto di vista relazione-database in quanto non è possibile aggiungere una relazione di chiave esterna a NodeContentRelationship.ContentId, anche se è una colonna di chiave esterna.

Tuttavia, la soluzione è abbastanza semplice e potente, quindi sono riluttante a cambiarla.

Cosa ne pensi? Sono in cerca di un mondo di dolore in pista?

Answer 1

Perché è impossibile impostare NoteContentRelationship.ContentId come chiave esterna? È possibile utilizzare facilmente un modello di eredità relazionale con una tabella Content che rappresenta una classe base astratta e varie tabelle AnimalContent , CarContent , ecc. Che rappresentano derivate classi.

Answer 2

Fai attenzione al Effetto piattaforma interna .

Se stai cercando di creare un "framework estensibile" che consenta agli sviluppatori di archiviare dati di diversi "tipi di contenuto" e di collegarli tra loro in modo generico, potresti scoprire che altri hanno già risolto questo problema .

Answer 3

Mi sembra una variante del design EAV (Entità, Attributo, Valore).

I vantaggi e gli svantaggi della progettazione EAV sono stati ampiamente documentati.

Ecco una descrizione di EAV da un punto di vista simpatico:

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

Ed eccone uno da un punto di vista ostile:

http: // tonyandrews .blogspot.com / 2004/10 / otlt-e-EAV-due-big-design-mistakes.html

Siate consapevoli del rovescio della medaglia di EAV prima di impegnare migliaia di ore-uomo nel riversare i dati in esso. È estremamente seducente per i programmatori, ma può diventare l'incubo di un gestore di dati.

Answer 4

Sei in cerca di un mondo di dolore lungo la strada se mai vuoi davvero riferire su questi dati. Hai appena reso molto più difficile scrivere join e così via. La mancanza di vincoli è negativa, ma il lavoro extra necessario per le query è (IMHO) peggiore.

Tuttavia, se si desidera che altri sviluppatori siano in grado di estendere il sistema e archiviare i dati nel database ma non essere in grado di modificare lo schema del database, potrebbe non esserci una scelta. In tal caso, la risposta è minimizzare quanto viene memorizzato in questo modo. Puoi anche accelerarlo leggermente sostituendo ContentType con un ContentTypeId definito in un'altra tabella.