SQL: один внешний ключ ссылается на первичный ключ в одной из нескольких таблиц

Question

Я работаю над приложением, которое будет использоваться в качестве расширяемой структуры для других приложений.

Один из фундаментальных классов называется узлом, а узлы - содержимым. Таблицы SQL выглядеть следующим образом:

ТАБЛИЦА Node (NodeId INT, .... и т.д.)

ТАБЛИЦА NodeContentRelationship (NodeId INT, ТипСодержимого строка, ContentID целое)

Это будет до разработчиков расширение приложения для создания собственных типов контента.

Очевидно, что это плохо с точки взаимоотношениях зрения базы данных, как это не представляется возможным, чтобы добавить внешний ключ отношения к NodeContentRelationship.ContentId, несмотря на то, что является внешнего ключа столбца.

Однако решение довольно простое и мощное, поэтому я не хочу его менять.

Как вы думаете, я нахожусь в мире боли на трассе?

Answer 1

Почему невозможно установить NoteContentRelationship.ContentId в качестве внешнего ключа? Вы можете легко использовать модель реляционного наследования с таблицей Content, представляющей абстрактный базовый класс, и различными таблицами AnimalContent, CarContent и т. Д., Представляющими производные классы.

Answer 2

Опасайтесь Inner Platform Effect.

Если вы пытаетесь построить «расширяемую платформу», которая позволяет разработчикам хранить данные различных «типов контента» и связать их друг с другом в общем виде, вы можете обнаружить, что другие уже solvedthisproblem.

Answer 3

Это выглядит как вариант в дизайне EAV (Entity, Attribute, Value).

Преимущества и недостатки конструкции EAV были широко задокументированы.

Вот описание EAV с симпатической точки зрения:

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

А вот один из враждебной точки зрения:

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

Будьте в курсе минуя EAV, прежде чем вы совершаете тысячи человеко-часов в заливки данных в него. Это невероятно соблазнительно для программистов, но это может стать кошмаром диспетчера данных.

Answer 4

Вы находитесь в мире ранений по дороге, если вы когда-нибудь захотите сообщить об этих данных. Вам просто стало намного труднее писать такие объединения. Отсутствие ограничений плохое, но дополнительная работа, необходимая для запросов, хуже (IMHO).

Однако, если вы хотите, чтобы другие разработчики могли расширять систему и хранить данные в базе данных, но не могли изменять схему базы данных, выбор может быть невозможен. В этом случае ответ заключается в том, чтобы свести к минимуму количество хранимых данных таким образом.Вы также можете немного ускорить его, заменив ContentType на ContentTypeId, определенный в другой таблице.