SQL：一个外键引用多个表之一中的主键

Question

我正在开发一个应用程序，它将用作其他应用程序的可扩展框架。

其中一个基本类称为Node，Nodes具有Content。 SQL表如下所示：

TABLE节点（NodeId int，.... etc）

TABLE NodeContentRelationship（NodeId int，ContentType string，ContentId int）

扩展应用程序的开发人员将创建自己的内容类型。

显然，从关系数据库的角度来看，这是不好的，因为无法向NodeContentRelationship.ContentId添加外键关系，即使 是外键列。

然而，解决方案非常简单和强大，所以我不愿意改变它。

你怎么看？我是否正在追寻一个痛苦的世界？

Answer 1

小心Inner Platform Effect。

如果您正在尝试构建一个“可扩展框架”，允许开发人员存储不同“内容类型”的数据并以通用方式将它们相互关联，您可能会发现其他人已经solved this problem。

Answer 2

为什么不能将NoteContentRelationship.ContentId设置为外键？您可以轻松地使用表示抽象基类的表Content的关系继承模型，以及表示派生类的各种表AnimalContent，CarContent等。

Answer 3

这在我看来就像EAV（实体，属性，价值）设计的变体。

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来稍微加快速度。