2

我意识到可能存在类似的问题,但我找不到足够接近指导的问题。替代键作为复合键上的外键

鉴于这种规范,

Site 
--------------------------- 
SiteID  int identity 
Name  varchar(50) 

Series 
--------------------- 
SiteID  int 
SeriesCode varchar(6) 
... 
--SeriesCode will be unique for every unique SiteID 

Episode 
---------------------- 
SiteID  int 
SeriesCode varchar(6) 
EpisodeCode varchar(10) 
... 

我提出的设计/实施

Site 
---------------------------- 
SiteID  int  identity 
Name  varchar(50) 


Series 
------------------------------------------- 
SeriesID int  identity, surrogate key 
SiteID  int   natural key 
SeriesCode varchar(6) natural key 
UNIQUE(SiteID, SeriesCode) 
... 

Episode 
------------------------------------------- 
EpisodeID int  identity, surrogate key 
SeriesID int  foreign key 
EpisodeCode varchar(6) natural key 
... 

什么问题呢?在这里将SeriesID代理作为外键*可以吗?我不确定是否遗漏了可能出现的任何明显问题。或者,使用复合自然键(SiteID + SeriesCode/SiteID + EpisodeCode)会更好吗?从本质上讲,这将解耦来自Series系列表的Episode表,并不适合我。

值得注意的是,在原始输入数据中,SeriesCode看起来像'ABCD-1'和EpisodeCode,它将填充这些表格,所以这是另一件可以改变的东西。

*:“虚拟”的外键,因为它是由上级预先决定,我们不应该使用实际外键

回答

4

是的,这一切都看起来很好。我可能做的唯一(次要)点是,除非另有第4个子表挂在Episode上,否则可能不需要EpisodeId,因为Episode.EpisodeCode是一个足以在Episode中标识和查找行的单一属性自然键。当然,将它留在那里并不是什么坏处,但作为一般规则,我添加了代理键作为子表中FK的目标,并尝试为每个表添加一个内容键以识别和控制冗余数据行。所以如果一张桌子没有其他FK引用它的表格(并且永远不会),我有时候不会在里面包含一个代理键。

+0

好点。事实上,将会有附加的表与情节相关联。这些只是整个数据库的基表。 – 2009-10-27 17:57:07

1

什么是“虚拟”外键?上级决定不使用外键约束吗?在那种情况下,你根本不使用外键。你只是假装。

并且是Episode实体的最佳选择?这不是真的意味着Show或Podcast等等,而是恰好总是现在是一系列的一部分?如果是这样,未来会发生什么变化? Episode最终会被滥用以包含系列之外的Show吗?在这种情况下,通过系列将Episode连接到Site可能会困扰你。

考虑到这一切,并假设你作为一个咕噜声可能无法改变它:如果我是你,我会尽可能使用自然键感到更安全。在没有外键约束的情况下,它可以更容易地识别错误数据,如果稍后必须诉诸某种SeriesCode ='EMPTY'技巧,那么使用自然键也更容易。

+0

确实没有FK的限制。 至于实体的选择,它是一个网络电视查看数字的数据库,它将被绑定到现有的普通电视放映数据库中,用于并排显示查看数字。已经决定顶层将成为“系列”或“季节”,然后将会有整个电视节目,相关剪辑和额外/奖励素材。可能最终会调用“Episodes”“剪辑”。将没有独立的剪辑没有被注册为“系列”,但正如你所指出的那样,为未来开放这个门是一个好主意。 – 2009-10-27 17:54:19

0

我的建议:

使用自然/业务作为主键时,除了在以下3种情况可能

  1. 自然/业务的关键是在插入
  2. 的时刻 未知
  3. 自然/商业关键是不好(这不是唯一的,它很容易改变)
  4. 自然/业务的关键是超过3列的复合材料和表格将有子表

在情况1和2的替代关键是需要选用

在情况3中,代理键强烈推荐推荐