您是否可以在自然ID上创建关系或使用内部ID并模拟自然ID关系？

Question

  

可能重复：
  Surrogate Vs. Natural/Business Keys

如果给出两个表，Level1 [ID，Title，Number] Level2 [ID，FKID ???，Title，Number]

系统的用户理解Level2与Level1有关，并且基于Level1的编号，我的问题是，您是否会根据内部ID建立关系并“模拟”与“Number”的关系，或者您会只需使用“数字”字段并完成它？

Answer 1

关于数据库ID而不是自然ID的两个标准原因是：

1. 很难保证自然身份证在任何情况下都不会改变
2. 通常，自然ID占用的空间更多，并且索引的效率不如数据库ID（尽管这当然不是很难和快 - 它取决于构成您的自然ID的数据）。通过使用数据库ID，您可以避免重复业务数据。

Answer 2

这个讨论在这里被打死了。很少有人只保护自然键，大多数人鼓励使用代理键。有人说你可以同时拥有两者，当然这是正确的（使用自然键，因此强制执行业务规则。）

如果自然键真的是一个键，我倾向于三思而后行（大多数情况下它不是。）。如果是，那我就用它。

但同样，实际上大多数自然键不是键，并且由于各种原因会有重复。例如，在签发国民身份证的国家/地区，找到两个具有相同身份证号码的人并不罕见。

那就是说，如果我去代理关键路线，我会像这样设置表格

Level1 [ID, Title, Number] Level2 [ID, FKID references Level1]

无需将标题和数字存储两次。

Answer 3

我认为这已被多次覆盖。

将IDENTITY / AUTONUMBER用作外键几乎总是更安全。

大多数自然键可以重复（即使出错）。

在我的国家，我们甚至遇到人员身份证号码X - 的问题。

Answer 4

如果'Number'列可以用于以自然的方式关联这两个表，我不会强制基于内部（代理）键的关系。

一方面，'Number'列可能已经足够好了，因此您不会在ID列中浪费空间。另一方面，如果'Number'列没有正确的特性（可能会改变，可能难以索引等），那么代理ID可能是更好的选择。

这一切都归结为'Number'列的语义。

Answer 5

• 有时最好使用自然 键如果（例如SSN，或 员工ID）您确信钥匙 稳定性。

• 使用代理键，FK就是 本质上是一个人的关系 系统生成＃，到另一个系统 生成＃。在极端情况下，这样 人为的关系可能是 与现实完全不同步。

• 其他海报评论了自然键必须改变时发生的混乱。当然这是一个问题。但值得研究的是这些例外情况会发生在你身上的频率 - 尾巴（例外）是否应该摇尾巴（你的设计） - 在每种情况下？

• 我对此并不狂热，但我同意在同一个数据库中使用自然和代理键混合使用不同的约定是不方便的。

• 如果自然键是多个字段 ，说DateOfBirth + LastName + 部门（或一些这样的奇怪 事情），然后你最好使用 人工钥匙。

以上所有参数均位于数据模型的逻辑级别。在物理层面，您的情况，服务器和性能限制将决定您的决策。最好不要过早地优化。