哪种设计方法更好：为数据库中的每种数据类型建立单独的链接/关联表，还是将通用标识合并到公共链接/关联表中？
因为如果没有例子这个问题真的没有意义......
假设我有一个数据库，其中包含作者和书籍的数据（使用人们可以轻松掌握和识别的示例）。为了简单起见，每个表格如下所示：
Authors
Id
Name
Books
Id
作者ID
Title
ISBN
我决定将这两组数据的链接包含到其他系统（Amazon、Barnes & Noble、Books-A-Million 等）中。我已经为 LinkTypes、LinkSources 和 LinkBases 创建了表：
链接类型
Id
姓名（例如书籍、作者）
链接源
Id
名称（例如 Amazon、B&N 等）
链接库
Id
链接类型ID
链接源ID
UrlBase（例如，http://www.amazon.com/book.html?id= http://www.amazon.com/book.html?id={0})
以及实际链接的表格：
Links
Id
链接类型ID
链接源ID
ReferenceValue（该值被替换到关联的 UrlBase 中以创建实际链接）
到目前为止，我一直在考虑为与作者和书籍相关的链接创建单独的表。这些表格看起来像：
作者链接
AuthorId
LinkId
对于两种不同类型的数据来说，这可能没问题，但是当我决定扩展数据库以包括出版商、讨论组、流派以及我可以提供可用链接的任何其他类型的数据时，会发生什么情况？这仍然是好的设计吗（或者一开始就是好的设计）？
我正在考虑的一个选项是修改 Links 表以包含 AssociationId 列，该列不与特定类型的数据绑定，但将用于建立必要的链接。这种方法消除了单独的关联表，但从长远来看，它可能会给设计带来一定程度的混乱。
有什么想法更好的设计吗？如果我需要提供更多详细信息，请告诉我。
我问了一个类似的问题并得到了一些有趣的答复：多个实体的通用一对多表 https://stackoverflow.com/questions/2862918/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
我认为你不需要LinkSourceID on the Link表，因为您已经有一个返回到的链接LinkBase其中包含LinkSourceID.
我的另一个想法是，如果引用完整性很重要，那么您可能希望避免第二个选择，因为您无法在您的数据库上维护外键。Links具有泛型的表AssociationID.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
