如果给定两个表，Level1 [ID, Title, Number] Level2 [ID, FKID???, Title, Number]
系统的用户知道 Level2 与 Level1 相关，基于 Level1 的 Number，我的问题是，你会根据内部 ID 建立关系并“模拟”与“Number”的关系，还是会只需使用“数字”字段即可完成？
【问题讨论】：
标签： database database-design foreign-key-relationship relationship
在数据库 ID 而非自然 ID 上关联的两个标准原因是：
【讨论】：
这个讨论已经在这里被打死了。很少有人只保护自然键，大多数人鼓励使用代理键。有人说你可以两者兼得，当然这是真的（使用自然键，以便强制执行业务规则。）
如果自然键真的是键（大多数时候不是），我倾向于三思而后行。如果是，那我就用它。
但同样，现实中的大多数自然键都不是键，并且由于各种原因会出现重复。例如，在签发国民身份证的国家，发现两个人的身份证号码相同的情况并不少见。
也就是说，如果我要走代理键路线，我会像这样设置表格
Level1 [ID, Title, Number] Level2 [ID, FKID references Level1]
无需将标题和编号存储两次。
【讨论】：
我想这已经被报道过很多次了。
使用 IDENTITY/AUTONUMBER 作为外键几乎总是更安全。
大多数自然键都可以复制（即使是错误的）。
在我的国家，我们甚至对人的个人身份证号码 X-) 有问题。
【讨论】：
如果“数字”列可用于以自然方式关联两个表，我不会强制基于内部（代理）键的关系。
一方面，“数字”列可能已经足够好，因此您不会在 ID 列上浪费空间。另一方面，如果“编号”列没有正确的特征（可能会更改、可能难以索引等），那么代理 ID 可能是更好的选择。
这一切都归结为“数字”列的语义。
【讨论】：
有时最好使用天然的 if 键（例如 SSN 或 员工 ID）您可以放心 稳定性。
使用代理键，FK 是 本质上是一种关系 系统生成#，到另一个系统 生成#。在极端情况下，例如 人为的关系可能是 与现实完全不同步。
其他张贴者评论了当自然键必须更改时发生的混乱。当然那是个问题。但值得研究一下这些异常对你来说发生的频率——尾巴（异常）是否应该摇摆不定（你的设计）——在每种情况下？
我对此并不狂热，但我同意在同一个数据库中使用自然键和代理键混合使用不同的约定很不方便。
如果自然键是多个字段 ，说 DateOfBirth + LastName + 部门（或一些这样奇怪的 事情），那么你最好使用 人工钥匙。
以上所有论点都处于数据模型的逻辑级别。在物理层面上，您的情况、服务器和性能限制将决定您的决定。最好不要过早优化。
【讨论】：