3

据我了解，自然键的纯粹主义者和代理键的纯粹主义者之间正在进行一场战争。喜欢这篇文章（还有更多）的人说“自然键对你不好，总是使用代理......

但是，我要么是愚蠢的要么是盲目的，但我看不到总是拥有代理键​​的理由！

假设您在配置中有 3 个表，如下所示：链接表

为什么我需要一个代理键呢？我的意思是没有它是完全有道理的。

另外，有人可以解释一下为什么主键永远不应该根据代理键纯粹主义者而改变吗？我的意思是，如果我说color_id VARCHAR(30)并且 key is black，并且我不再需要 black 因为我将其更改为charcoal，那么为什么将blackkey 更改为charcoal以及所有引用列也是一个坏主意？

编辑：刚刚注意到我什至不需要更改它！只需创建一个新的，更改引用列（就像我对代理键所做的一样），然后让旧的保持平静......

在代理键咒语中，我需要然后创建额外的条目，比如id=232和name=black. 这对我有什么好处？我在桌子上有一把备用钥匙，我不再需要了。另外我需要加入以获得颜色名称，否则我可以留在一张桌子上并快乐吗？

请向 5 岁的孩子解释一下，请记住，我并不是要说“代理键不好”，我想理解为什么有人会说“总是使用代理键！”之类的话。

4

3 回答 3

7

代理键在存在次优自然键的情况下很有用：不多也不少。次优的自然键将是 GUID 或 varchar 或其他宽/无序的。

然而，使用代理的决定是在概念和逻辑建模过程之后的实施决定，基于对所选 RDBMS 如何工作的了解。

但是，“拥有代理键​​”的最佳实践现在是“始终拥有代理键​​”，并且立即引入。对象关系映射器还经常向所有表添加代理键，无论是否需要，这都无济于事。

对于链接（多对多）表，您不需要一个：SQL：您是否需要多对多表的自动增量主键？. 对于具有 2 个 int 列的表，开销是代理列数据的额外 50%（假设为 int 并忽略行元数据）

于 2013-05-13T08:14:38.333 回答
1

好吧，我自己更喜欢自然键:)

但是代理键可以有它的优势，即使你像我一样想一直“自然”:)

例如，我有一个表，由于各种限制，必须将其定义为依赖于其他表。就像是

Table Fee (
foreign_key1,
foreign_key2,
foreign_key3,
value)

记录由三个外键定义/标识，但同时，您最多可以有 2 个外键为空。所以你不能将它们创建为主键（你只需在 3 列上放置一个唯一的）为了在该表上有一个主键，唯一的方法是使用代理:)

现在...为什么不更改主键...这可以认为是很哲学的...我是这样看的，希望它有意义...主键本身不仅仅是一个组合unique+not null ，更多的是关于“记录的真正本质”，它定义了核心的记录。从这个意义上说，这不是你可以轻易改变的东西，对吗？

以自己为例。你有一个昵称，但它并不能定义你的真实身份。你可以改变它，但做你自己的本质不会改变。现在，如果你保持昵称，但改变你的本质......它仍然是同一个人吗？不，将其视为“新”人会更有意义......对于记录来说，它是一样的......

这就是为什么您通常不更改主键并从头开始定义新记录的原因

于 2013-05-13T08:11:27.763 回答
0

永远记住代理键是我们实际表列的附加列让我们采用如下表列

patient_name
address
mobile_no
email_address

看到这里假设我们正在处理患者记录的录取，所以在这里我们不能使用mobile_no主键，因为我们可以使用但有些人可能没有移动号码，而不是使用代理键并将其作为主键并变为实际键mobile_no，patient_name作为主键，我们可以轻松地执行..如果移动设备没有改变没问题，我们仍然可以在代理键的帮助下进行搜索，如下所示..

在这里，您可以在实际数据的顶部写代理键

patient_no----->primary key[surrogate key]
patient_name ---->pk
address
mobile_no--->pk
email_address
于 2018-06-05T18:10:24.427 回答