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

Question

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

既然这个问题没有例子真的没有意义......

假设我有一个包含作者和书籍数据的数据库（使用一个人们可以轻松掌握和识别的示例）。为简单起见，每个表如下所示：

作者

身份证
名称

书籍

身份证
作者ID
标题
国际标准书号

我决定将这两组数据的链接包含到其他系统（亚马逊、Barnes & Noble、Books-A-Million 等）中。我已经为 LinkTypes、LinkSources 和 LinkBases 创建了表：

链接类型

身份证
姓名（例如，书籍、作者）

链接源

身份证
名称（例如，Amazon、B&N 等）

链接库

身份证
LinkTypeId
链接源ID
UrlBase（例如，http://www.amazon.com/book.html?id={0}）

以及实际链接的表格：

链接

身份证
LinkTypeId
链接源ID
ReferenceValue（这个值被代入关联的 UrlBase 以创建实际链接）

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

作者链接

作者ID
链接ID

这可能适用于两种不同类型的数据，但是当我决定扩展数据库以包括出版商、讨论组、流派和任何数量的其他类型的数据时会发生什么，我可以获得链接？这仍然是好的设计（还是一开始就是好的设计）？

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

你有什么想法更好的设计吗？如果我需要提供更多详细信息，请告诉我。

Answer 1

我问了一个类似的问题，得到了一些有趣的回答：Common one-to-many table for multiple entities

我认为最好的解决方案是使用继承。创建一个抽象实体（我称它为项目，但我确信有一个更好的名称），它代表作者、书籍或任何其他可能具有链接的东西。你最终会得到这样的结果：

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

我认为您不需要Link 表上的LinkSourceID，因为您已经有一个返回到包含LinkSourceID 的LinkBase 的链接。

我的另一个想法是，如果引用完整性很重要，那么您可能希望避免使用第二种选择，因为您无法使用通用 AssociationID 在 Links 表上维护外键。

Answer 2

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