代理密钥是否应该向用户公开？

通常，在没有自然键的表中，对于用户来说，拥有唯一生成的标识符仍然很有用。如果表具有代理主键（在这种情况下，您一定会希望它具有），该键应该向用户公开还是应将另一个字段用于该目的？

不公开代理键的原因之一是，现在您不能执行保留记录之间关系的操作，而只能更改键值，例如某些类型的删除/重新插入，将数据从一个数据库复制到数据库的许多方法。另一个等等

公开代理键的主要优点是使用您拥有的字段非常简单。

在什么情况下最好直接向用户公开代理密钥？

您需要为暴露给需要更改的用户/客户的任何标识符做好准备，并且更改数据库中行的标识并将更改传播到所有外键只是要求中断数据。

如果数据没有自然业务密钥，则可以为“业务标识符”添加一个附加字段。应该针对所使用的流程进行优化。电话键盘输入仅表示数字。通过电话/语音方式避免使用类似的发音符号（B / D，M / N等）。您甚至可以自动生成一些容易记忆的短语（“绿色果冻”）。

这样做的结果是，企业以后可以更改他们想要引用记录的方式，唯一的数据模式更改是为该ID类型添加新列或转换已经存在的ID。更改不会在整个数据库中传播，并且您仍然具有一个随时间有效的ID（代理）。

简而言之，我将避免向用户公开代理键。正如评论所指出的那样，代理密钥几乎应该永远不会改变。相反，企业希望改变一切。如果代理密钥被公开，则企业要更改它只是时间问题。

附带说明一下，当我在此处说“公开”时，是指将密钥提供给用户，希望他们直接使用它（例如致电要求提供其订单号）。

在某些情况下，代理密钥是预期的并且对用户有意义。我最喜欢的示例是“订单号”。订单号并不是真正的自然键：自然键可能是时间戳加用户，或者如果您希望用户在时间戳的粒度范围内生成多个订单，则可能会更多。

但是，用户理解并期望订购号的便利。如果您让用户知道它们，则没有害处，也有很多价值。

另一方面，某些代理键对用户没有意义。当然，我的健康保险公司有一些代用密钥，可以根据我的会员ID，出生日期，携带者等来识别我，但是我不在乎，我关心我卡上的信息（通常包括基于ID的ID）在我的雇主身上，并且在整个世界上都不是唯一的...因此，保险公司的代理钥匙）。

如果代理密钥是正确生成的GUID / UUID *，则仅应公开它。公开连续代理密钥是OWASP十大安全问题中的第4个。

*实际上，最好假定它不是出于这些目的而正确生成的，除非您知道它是由密码安全的随机或伪随机数生成器创建的。

如果表没有自然键，则代理键允许这样的行。

surrogate_key  some_name
--
1              Wibble
2              Wibble
...
17             Wibble
...
235            Wibble

我称这些人工键代替代理键，但是这种区别对这个问题并不重要。

现在，假设有重要数据通过外键引用这些代理键，那么如果最终用户不知道代理键值，最终用户将如何知道要更新哪一行？

用外行的话来说：

• 应该向用户隐藏代理。
• 您应该向用户公开其他一些业务候选键。
• 如果不存在其他候选密钥，则应显示PK。但是在这种情况下，由于PK不能替代其他列，因此不被视为代理。

您只应向用户公开一个字段，该字段可以直接或向您报告缺陷时向用户提供有用的信息。

相反，当“代理主键”是识别用户执行的交互的记录（简单或复杂）的主要手段时，则应始终公开“代理主键”。

您是否将密钥公开给最终用户都没有关系。您的应用程序应执行必要的授权，例如，仅知道订单ID便无法允许他们访问通常无法访问的内容。

注意：这里假设基于Web或n层的应用程序可以/可行进行服务器端授权。如果您有直接执行sql的VB应用程序，那就是整个“另一个问题”。