代理键作为复合键的外键

Question

我意识到可能存在类似的问题，但我找不到足够接近的问题来提供指导。

根据此规范，

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）会更好吗？从本质上讲，这会将剧集表与系列表分离，但这不适合我。

值得补充的是，在填充这些表的原始输入数据中，SeriesCode 看起来像“ABCD-1”，EpisodeCode 看起来像“ABCD-1NMO9”，所以我想这是另一件事可以改变。

*：“虚拟”外键，因为之前是上级决定的，所以我们不应该使用实际外键

Answer 1

是的，一切看起来都很好。我可能提出的唯一（次要）观点是，除非您有另一个第四个子表挂在 Episode 上，否则您可能不需要 EpisodeId，因为 Episode.EpisodeCode 是足以识别和定位 Episode 中的行的单个属性自然键。当然，把它留在那里并没有什么坏处，但作为一般规则，我添加代理键作为子表中 FK 的目标，并尝试向每个表添加一个自然键来识别和控制冗余数据行......因此，如果一个表没有其他表有 FK 引用它，（而且永远不会）我有时不会费心在其中包含代理键。

Answer 2

我的建议：

尽可能使用自然/业务作为主键，但以下 3 种情况除外：

1. 插入时自然/业务键未知
2. 自然/业务键不好（它不是唯一的，容易经常改变）
3. 自然/业务键是超过3列的组合，并且该表将有子表

在这种情况下1 和 2 需要代理键。

在情况 3 中，强烈建议使用代理键。

Answer 3

什么是“虚拟”外键？是不是高层决定不使用外键约束？在这种情况下，您根本就没有使用外键。你只是假装而已。

Episode 是实体的最佳选择吗？它不是真的意味着“节目”或“播客”之类的东西，而且现在恰好总是系列的一部分吗？如果是这样，未来情况会改变吗？剧集最终会被滥用以涵盖系列之外的节目吗？在这种情况下，通过系列将剧集与站点绑定可能会再次困扰您。

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