SQL：一个外键引用几个表之一中的主键答案

【问题标题】：SQL : one foreign key references primary key in one of several tablesSQL：一个外键引用几个表之一中的主键
【发布时间】：2008-11-17 05:50:12
【问题描述】：

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

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

TABLE 节点（NodeId int, .... 等）

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

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

显然，从关系数据库的角度来看，这很糟糕，因为无法将外键关系添加到 NodeContentRelationship.ContentId，即使它是一个外键列。

但是，解决方案非常简单且功能强大，因此我不愿意更改它。

你怎么看 - 我会在赛道上陷入痛苦的世界吗？

【问题讨论】：

【解决方案1】：

当心Inner Platform Effect。

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

【讨论】：

【解决方案2】：

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

【讨论】：

所以你的意思是架构看起来像这样： TABLE Node ( NodeId int, .... etc ) TABLE AnimalContent ( AnimalContentId int, NodeId int, IsMammal ... etc) TABLE CarContent ( CarContentId int, NodeId int...等）你是对的 - 从关系数据库的角度来看会更好。

【解决方案3】：

这在我看来像是 EAV（实体、属性、值）设计的变体。

EAV 设计的优点和缺点已被广泛记录。

以下是从同情的角度对 EAV 的描述：

这是从敌对的角度来看的：

在投入数千个工时将数据注入其中之前，请注意 EAV 的缺点。它对程序员来说极具诱惑力，但它可能成为数据管理员的噩梦。

【讨论】：

【解决方案4】：

如果您想要实际报告这些数据，那么您将面临一个痛苦的世界。你只是让编写连接等变得更加困难。缺乏约束很糟糕，但查询所需的额外工作（恕我直言）更糟。

但是，如果您希望其他开发人员能够扩展系统并将数据存储在数据库中，但不能更改数据库架构，则可能别无选择。在这种情况下，答案是尽量减少以这种方式存储的数量。您还可以通过将 ContentType 替换为另一个表中定义的 ContentTypeId 来稍微加快速度。

【讨论】：