针对不同数据的单独链接/关联表?

时间:2010-06-30 15:06:49

标签: database-design

哪种设计方法更好:为数据库中的每种数据类型分配链接/关联表,或将通用标识合并到公共链接/关联表中?

因为如果没有一个例子,这个问题真的没有意义......

假设我有一个包含作者和书籍数据的数据库(使用人们可以轻松掌握和识别的例子)。为简单起见,每个表格如下:

作者

标识
名称

图书

标识
AUTHORID
标题
ISBN

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

LinkTypes

标识
姓名(例如,书,作者)

LinkSources

标识
姓名(例如亚马逊,B& N等)

链接库

标识
LinkTypeId
LinkSourceId
UrlBase(例如,http://www.amazon.com/book.html?id= {0})

以及实际链接的表格:

链接

标识
LinkTypeId
LinkSourceId
ReferenceValue(此值将替换为关联的UrlBase以创建实际链接)

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

AuthorLinks

AUTHORID
LINKID

这可能适用于两种不同类型的数据,但是当我决定扩展数据库以包括发布者,讨论组,流派以及我可以提供链接的任何数量的其他类型的数据时会发生什么?这仍然是一个好的设计(或者它是一个好的设计开始)?

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

有哪些想法更好的设计?如果我需要提供更多详细信息,请告诉我。

2 个答案:

答案 0 :(得分:1)

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

我认为最好的解决方案是使用继承。创建一个抽象实体(我称之为Item但我确定有一个更好的名称),它代表一个Author,Book或任何其他可能有链接的实体。你最终会得到这样的东西:

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

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

我还有一个想法是,如果参照完整性很重要,那么您可能希望避免使用第二个选项,因为您无法使用通用LinksAssociationID表上维护外键。

答案 1 :(得分:0)

这看起来很像RDF商店,即图表数据库。如果是,请考虑使用现有实现。如果没有,请重新考虑您真正想要在数据库中建立的关系,并编写表来捕获这些关系。