SQL: una clave externa hace referencia a la clave principal en una de varias tablas

Question

Estoy trabajando en una aplicación que se utilizará como marco extensible para otras aplicaciones.

Una de las clases fundamentales se llama Nodo, y los Nodos tienen Contenido. Las tablas SQL se ven así:

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

TABLE NodeContentRelationship (NodeId int, ContentType string, ContentId int)

Dependerá de los desarrolladores extender la aplicación para crear sus propios tipos de contenido.

Claramente, esto es malo desde el punto de vista de la base de datos de relaciones, ya que no es posible agregar una relación de clave externa a NodeContentRelationship.ContentId, a pesar de que es una columna de clave externa.

Sin embargo, la solución es bastante simple y poderosa, así que soy reacio a cambiarla.

¿Qué piensas? ¿Estoy en un mundo de dolor en el camino?

Answer 1

¿Por qué es imposible establecer NoteContentRelationship.ContentId como una clave externa? Puede usar fácilmente un modelo de herencia relacional con una tabla Content que representa una clase base abstracta, y varias tablas AnimalContent , CarContent , etc. que representan derivadas clases.

Answer 2

Cuidado con el Efecto de plataforma interna .

Si está intentando crear un 'marco extensible' que permita a los desarrolladores almacenar datos de diferentes 'tipos de contenido' y relacionarlos entre sí de manera genérica, es posible que otros ya tengan resuelto este problema .

Answer 3

Esto me parece una variación en el diseño EAV (Entidad, Atributo, Valor).

Los beneficios y las desventajas del diseño de EAV han sido ampliamente documentados.

Aquí hay una descripción de EAV desde un punto de vista comprensivo:

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

Y aquí hay uno desde un punto de vista hostil:

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

Tenga en cuenta las desventajas de EAV antes de dedicar miles de horas hombre a verter datos en él. Es enormemente seductor para los programadores, pero puede convertirse en la pesadilla de un administrador de datos.

Answer 4

Estás en un mundo de dolor en el futuro si alguna vez quieres informar sobre estos datos. Acabas de hacer mucho más difícil escribir uniones y cosas así. La falta de restricciones es mala, pero el trabajo adicional necesario en las consultas es (en mi humilde opinión) peor.

Sin embargo, si desea que otros desarrolladores puedan ampliar el sistema y almacenar datos en la base de datos pero no puedan cambiar el esquema de la base de datos, es posible que no haya otra opción. En ese caso, la respuesta es minimizar cuánto se almacena de esta manera. También puede acelerarlo un poco reemplazando ContentType con un ContentTypeId definido en otra tabla.