为什么不公开主键

在我的教育中，我被告知将真实的主键（不仅是DB密钥，而且是所有主访问器）公开给用户，这是一个错误的想法。

我一直认为这是一个安全问题（因为攻击者可能会尝试读取自己的东西，而不是自己的东西）。

现在，我必须检查是否无论如何都允许用户访问，所以背后有其他原因吗？

另外，由于我的用户无论如何都必须访问数据，因此我需要在两者之间的某个外部世界拥有一个公共密钥。现在，公用密钥与主密钥存在相同的问题，不是吗？

人们一直要求有一个示例说明为什么仍然要这样做，所以这里是一个。请记住，这个问题不仅涉及原理本身，而且要在本示例中应用。明确欢迎解决其他情况的答案。

处理活动的应用程序（Web，移动设备）具有多个UI和至少一个用于系统间通信的自动API（例如，会计部门希望根据已完成的操作向客户收取多少费用）。该应用程序有多个客户，因此必须将其数据分开（从逻辑上讲，数据存储在同一数据库中）。无论如何，都会检查每个请求的有效性。

活动是非常精细的，因此它在某个容器对象中在一起，可以称之为“任务”。

三个用例：

1. 用户A希望将用户B发送给某个任务，因此他向他发送了一个链接（HTTP）以在其中完成一些活动。
2. 用户B必须走出建筑物，以便他在移动设备上打开任务。
3. 会计部门希望向客户收取该任务的费用，但使用第三方会计系统，该系统通过引用REST-API的某些代码自动加载任务/活动

每个用例都要求（或变得更加容易）代理为任务和活动提供一些可寻址的标识符。

另外，由于我的用户无论如何都必须访问数据，因此我需要在两者之间的某个外部世界拥有一个公共密钥。

究竟。使用无状态HTTP，否则该HTTP将不知道应请求什么资源：它218306在URL中公开您问题的ID 。也许您实际上想知道暴露的标识符是否可以预测？

我唯一听到否定答案的地方是这样做的：“但是他们可以更改URL中的ID！” 。因此，他们使用GUID而不是实施适当的授权。

我可以想像一种情况，您不希望标识符可预测：资源收集。如果你有一个公开托管的某些资源，其他人可能是有趣的网站，你会收留他们喜欢/images/n.jpg或/videos/n.mp4其中n仅仅是一个递增的数字，任何人都在看流量，并从您的网站可以收获所有的资源。

因此，直接回答您的问题：不，直接“公开”仅对您的程序有意义的标识符也不错，通常，程序成功运行甚至需要它。

您不应该公开它，因为看到它的人将开始使用它作为他们的“帐号”，而不是。例如，对于我的银行帐户，我知道我的帐号是什么。我已经记住了，我在电话上与客户服务一起使用，在填写表格供其他银行进行转账，法律文件，自动转帐服务等时使用。我不想要它改变了。另一方面，我不知道或从未见过（对于我的帐户而言）主键。
多年来，存储它的系统通过银行合并，系统升级和替换等从一个系统更改为另一个系统。
主键可能会通过其中的某些转换而更改，因此，如果它从未被公开，记录或记过，任何普通用户
没有业务意义的键通常称为代理键，通常（但并非总是）用作主键。

顺便说一句，当人们构建的接口和程序滥用并公开主键并使它们成为此类系统的一部分时，甚至在内部做事时，甚至会在内部发生这种情况-在内部唯一地标识数据库记录。我实际上是通过支持医院数据仓库系统的6年时间了解上述内容的。

因为主键是实现细节。

如果迁移数据库，则主键可能会由于插入顺序，删除旧记录等原因而发生变化，这有几个不同的原因。如果迁移数据库平台，则可能根本没有实际的主键。将PK暴露在数据访问层之上是一个泄漏的抽象，涉及所有耦合问题。

这是其他答案（也就是我所学到的）的组合答案。如果您想赞成这一点，则至少应赞成其他一项，因为他们做了实际的工作。如果您更感兴趣，请阅读其他答案。

您不应公开数据库主键，而应使用代理键

1. 如果您希望用户能够记住（至少一点点）或识别条目的标识符。（Graystone28s回答）
2. 如果您要提前计划并考虑可能会更改可能会更改PK的系统（数据库或其他）。（Telastyns回答）
3. 如果您想确保用户拥有一致的访问数据的方式，即使您的公司转移了所有权并且数据已经完全迁移到了另一个系统中，它也不会改变。（Michael Durrants回答）
4. 如果您的PK是可预测的（如序列），则您的系统可能会遇到资源获取问题。（CodeCasters回答）仅当您的系统具有值得收获的信息并且任何人或至少有收获兴趣的人可以访问的信息时，这才适用。

注意：您创建的密钥应该是人类可理解的（Sqlvogels Answer）。

如果您的系统不需要1.到4.，则没有理由不使用数据库PK作为您的公共标识符（答案中的几个）。同样，安全性不是这里的问题（有几个答案）。

我发现的一个原因是，在整个时间段内，我看到最终用户要求其标识符表示某种含义（例如带有前缀或接受该标识符的年份的指标）。更改PK很难，但是替代更容易。

您的主键可能是出于性能原因而希望数据库索引的内容，并且可能由于技术原因而及时将其更改，例如从数字更改为guid ...您只是不知道新技术或知识的原因是什么可能会引导您失望。您的pk是您的技术数据，公钥供最终用户使用。

对于大多数应用程序，确实必须向用户公开密钥。为了有效地使用信息系统，该系统的用户通常需要一种方法来识别其中的信息，并将该信息与数据库之外的世界相关联。用关系数据库术语来说，那些标识符是键。

一种常用的设计模式是为数据库表创建一个额外的纯“技术”键，作为抽象手段。例如，提供一个稳定的（相对不变）的密钥，其中某些替代密钥可能会发生变化。此类技术密钥通常不向最终用户公开，因为这样做会破坏从用户需求中提取预期的内容。它与安全性无关。

您的问题中隐含的问题/误解是由于不恰当地使用了主键一词。主键只是几个“候选”键（数据库表中的几个可能的标识符）之一。主键并不一定需要与其他任何键都有本质上不同的属性，因此专门适用于主键而不是其他键的断言和设计原则总是令人怀疑，而且常常是错误的。

鉴于您通常需要向用户公开密钥，该密钥应该是什么？尝试使您的钥匙熟悉，简单和稳定。熟悉和简单的操作使键易于阅读和记忆，并有助于避免数据输入错误。稳定性意味着不经常更改密钥，这也有助于避免错误识别的可能性。

这来自CodeCaster对Greystone28的回答的评论。这是您在说什么的示例：

我公开了InvoiceNumber，它具有客户的含义并且可以更改，但是我还公开了InvoiceID，我的代码使用该ID来唯一地标识发票。您不必（通常也不想）让用户键成为存储键。这个问题是关于后者的。

播放InvoiceID在您的应用程序中有什么用途？

通过暴露，我假设您的意思是用户可以看到它。仅在用户需要它才能使用您的应用程序时公开它。技术支持人员或某些管理人员都可以使用它。我已经使用了一些执行此操作的应用程序。当我知道有问题的特定记录时，确实可以更轻松地提供支持。

实体具有暴露给外界的唯一标识符是完全正常的。对于某些对象，可能会找到实际上具有含义的标识符（例如发票编号），而对于其他对象，则不存在这样的标识符，因此必须生成该标识符。

为了保持一致性和可读性，我发现对于系统中的所有实体来说，最好使用完全相同的类型和名称作为其标识符。通常，此标识符将<type> getId()在某些抽象基类中公开（）。

出于相同的原因，系统中的每个服务（例如发票服务）都应提供相同的方法来按其标识符访问实体。通常，此方法（findById(<type> id)）将从通用服务接口或基类继承。

此标识符不必是实体的主键，但可以是一个。唯一需要确保的是，密钥生成策略会生成合理的唯一标识符（不一定是全球唯一的标识符，至少在系统内）。

如果以后将系统迁移（以我的经验来看是很大的话）到另一个数据库，那么使用另一种策略（不基于主键）来创建标识符就不是问题，只要该策略与原始策略兼容即可。

主键在那里，就像您尝试作为开发人员访问的元组（记录，行）的句柄一样。它也用于参照完整性（外键约束）中，也许它也具有一个或多个用例。

从本质上讲，向用户甚至黑客公开它并没有什么不好。因为我不知道例如使用主键的攻击。

但是在安全性方面，我们有很多原则（我们接受并不同意），我们需要遵守这些原则：

1. 租赁特权原则
2. 默默无闻的安全

和其他一些原则。他们说的基本上是：

如果您不需要公开数据，那为什么还要呢？