代理键'preference‘解释

Question

据我所知，自然键的纯粹主义者和代理键的纯粹主义者之间正在进行一场战争。在这个点赞的this帖子(还有更多)中，人们说‘自然密钥对你不好，总是使用代理...

然而，无论我是愚蠢的还是盲目的，但我看不出有一个理由总是有代理键！

假设您在如下配置中有3个表：

​

为什么我需要一个代理密钥？？我的意思是，没有它是非常有意义的。

另外，有人能解释一下为什么根据代理键纯化者，主键永远不应该改变吗？我的意思是，如果我说color_id VARCHAR(30)，一个键是black，我不再需要黑色，因为我要把它改成charcoal，为什么把black键改成charcoal和所有引用列都是个坏主意？

编辑:我只是注意到我甚至不需要改变它！只需创建一个新的，更改引用列(就像我必须对代理键所做的那样)，并保留旧的……

在surrogate key mantra中，我需要创建额外的条目，比如id=232和name=black。这对我有什么好处呢？我桌子上有一把备用钥匙，我不再需要它了。另外，我需要加入才能获得一个颜色名称，否则我可以留在一张桌子上快乐？

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

Answer 1

在存在不太理想的自然键的情况下，代理键很有用:不多，也不少。次优的自然键将是GUID或varchar，或者宽/无序。

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

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

对于链接(多对多)表，您不需要一个：SQL: Do you need an auto-incremental primary key for Many-Many tables?。对于包含2个int列的表，额外的开销是surrogate列的数据的50% (假设为int并忽略行元数据)

Answer 2

好吧，我自己更多的是在自然键上:)

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

例如，我有一个表，由于各种约束，必须将其定义为依赖于其他表。就像这样

Table Fee (
foreign_key1,
foreign_key2,
foreign_key3,
value)

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

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

以你自己为例。你有一个缺口，但它并不能定义你到底是什么。你可以改变它，但做你自己的本质是不会改变的。现在，如果你保留了昵称，但改变了你的本质...还会是同一个人吗？不，把它当做一个“新人”会更有意义。对于记录来说是一样的..。

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

Answer 3

请始终记住，代理键是实际表列的附加列，让我们以如下所示的表列

patient_name
address
mobile_no
email_address

在这里，想象一下，我们正在处理患者记录的接收，所以这里我们不能使用mobile_no有主键，因为我们可以使用，但有些人可能没有手机no而不是这个go作为主键，并使其成为实际的mobile_no，patient_name作为主键，那么我们可以很容易地执行..here，如果移动设备没有更改，没有问题，我们仍然可以在代理键的帮助下进行搜索，如下所示。

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

patient_no----->primary key[surrogate key]
patient_name ---->pk
address
mobile_no--->pk
email_address