当使用自然键（而不是代理键）设计关系数据库时，数据问题有哪些类型？

Question

我看到此评论：

[应用]与数据最相关的问题是使用自然键的。

来源：Surrogate vs. natural/business keys

我想这更多的支持证据，作为注释留下太多的想象空间。

它表明使用自然键的练习会产生与数据相关的问题，但不会指定出错的地方......数据是否被损坏？不同步？变得错误，丢失，损坏？很难查询？

当使用自然键设计数据库与使用代理键相反时，会发生什么样的数据问题？使用代理键时如何防止这些类型的问题？

Answer 1

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

例如，假设您有邮政编码或邮政编码表。通常，这些都是邮政编码也是自然钥匙的地方。现在假设邮局改变一个特定的邮政编码（92680变为92780）。当您更改邮政编码表中的密钥时，您必须转到每个引用该邮政编码的表格，并在那里更新它。因此，邮政编码中有92680的客户地址，供应商地址等中的每一行都必须更改为92780.

很明显，如果相关表格未修复，您可能会遇到大问题。假设您根据邮政编码收取保险费。想象一下，如果这些问题未在优质表格中解决，那么您可能会遇到的问题。

使用代理键完全消除了这个问题。您只需更改邮政编码表中的邮政编码。代理键没有改变。由于相关表存储代理键，所以您不必更改其他任何内容。