Indexing 当使用自然键（而不是代理键）设计关系数据库时，它们会遇到什么类型的数据问题？

我看到这样的评论：

[应用程序]与数据相关的问题最多的是那些使用自然键的应用程序

资料来源：

我需要更多的证据来证明这一点，因为这一评论留下了很多想象

它表明，使用自然键的做法会产生与数据相关的问题，但并没有说明出了什么问题。。。数据是否损坏？不同步？变得错误、丢失、损坏？难以质疑

---

当数据库设计为使用自然键而不是使用代理键时，会出现哪些数据问题？在使用代理键时，如何防止此类问题？

自然键的主要问题是它如何影响相关表。如果更改键的值，则必须更正每个表中引用原始值的每一行

例如，假设您有一个邮政编码或邮政编码表。通常，邮政编码也被设计为自然密钥。现在假设邮局更改了一个特定的邮政编码（92680变为92780）。更改邮政编码表中的键时，必须转到引用该邮政编码的每个表，并在其中进行更新。因此，客户地址、供应商地址等中的每一行。。。邮政编码中的92680必须改为92780

显然，如果相关的表没有得到修正，您可能会开始出现大问题。比如说，你根据邮政编码收取保险费。想象一下，如果这些问题没有在premium表中解决，您可能会遇到哪些问题

---

使用代理键完全消除了这个问题。您只需在邮政编码表中更改邮政编码。代理项密钥未更改。而且，由于相关表存储代理项，因此您不必更改任何其他内容。

如果您的DBMS支持级联更新，则外键引用将自动更新。如果您的自然密钥未在任何地方引用，则无需更新。代理密钥也是如此。你提出了一个很好的观点。需要指出的是，仅仅因为您的DBMS支持级联更新，并不意味着一切都会自动处理。我在SQL Server中做了很多工作，它支持级联更新。我记不起上一次看到级联更新是什么时候了，它设置了所有其他需要的引用完整性，从而使事情变得“自动”。但是，是的，如果您正确设置了所有内容，系统应该能够处理您的更新。如果使用自然关键点，这是首选方法。