Database design 不同数据的单独链接/关联表？

哪种设计方法更好：为数据库中的每种类型的数据提供单独的链接/关联表，还是将通用标识合并到公共链接/关联表中

如果没有一个例子，这个问题真的没有意义

假设我有一个数据库，其中包含作者和书籍的数据（使用一个人们容易理解和认同的示例）。为了简单起见，每个表的表如下所示：

作者 Id
名字

书 Id
AuthorId
标题
ISBN

我决定将这两组数据的链接包含到其他系统中（Amazon、Barnes&Noble、Books-A-1000000等）。我已经为链接类型、链接源和链接库创建了表：

链接类型 Id
姓名（如书籍、作者）

链接源 Id
名称（如亚马逊、B&N等）

链接库 Id
链接类型ID
LinkSourceId
UrlBase（例如，{0}）

以及实际链接的表格：

链接 Id
链接类型ID
LinkSourceId
ReferenceValue（该值被替换到关联的UrlBase中以创建实际链接）

到目前为止，我一直在考虑为与作者和书籍相关的链接创建单独的表。这些表看起来像：

作者链接 AuthorId
链接ID

这可能适用于两种不同类型的数据，但当我决定将数据库扩展到包括出版商、讨论组、流派以及我可以提供链接的任何其他类型的数据时，会发生什么情况？这仍然是一个好的设计吗（或者从一开始就是一个好的设计）

我正在考虑的一个选项是修改Links表以包含AssociationId的列，该列不绑定到特定类型的数据，而是用于建立必要的链接。这种方法消除了单独的关联表，但可能会给长期设计带来一定程度的混乱

---

你认为哪种设计更好？如果我需要提供更多详细信息，请告诉我。

这看起来非常像RDF存储，即图形数据库。如果是，考虑使用现有的实现。如果没有，请重新思考您真正希望在数据库中拥有的关系，并编写表来捕获这些关系。

我问了一个类似的问题，得到了一些有趣的回答：

我认为最好的解决方案是使用继承。创建一个抽象实体（我称之为Item，但我相信还有更好的名称）来表示作者、书籍或其他可能有链接的内容。你会得到这样的结果：

Item      Author    Book       LinkBase        Link
=======   =======   =========  ==========      ========
ItemID    ItemID    ItemID     LinkBaseID      LinkBaseID
          Name      AuthorID   LinkTypeId      ItemID
                    Title      LinkSourceId    ReferenceValue
                               ReferenceValue

我认为您不需要在

Link

表上显示

LinkSourceID

，因为您已经有了一个指向

LinkBase

的链接，其中包含

LinkSourceID

我的另一个想法是，如果引用完整性很重要，那么您可能希望避免第二个选项，因为您无法使用通用的

AssociationID

在

链接
表上维护外键（至少据我所知，它不是图形数据库）。我不知道你在建议什么，我在这里重新思考。我觉得我对这段感情很清楚。我提出了两种不同的关系设计，并要求反馈哪种方法更好。