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

Question

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

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

TABLE Node (NodeId int, .... и т. Д.)

TABLE NodeContentRelationship (NodeId int, строка ContentType, ContentId int)

Разработчики, расширяющие приложение, будут создавать собственные типы контента.

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

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

Как вы думаете, я в мире боли в будущем?

Answer 1

Остерегайтесь эффекта внутренней платформы .

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

Answer 2

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

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

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

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