向用户透露行的主键是否不安全？
为什么许多应用程序在向用户显示记录时会用看似随机的替代 ID 替换数据库的主键？
我的猜测是，它可以防止用户猜测表中的其他行。如果是这样，这不是虚假的安全感吗？
Why do many applications replace the primary key of a database with a seemingly random alternative id when revealing the record to the user?
My guess is that it prevents users from guessing other rows in the table. If so, isn't that just false sense of security?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我猜你在这里谈论的是代理键。代理键的期望或假设的优点之一是它们不受任何外部含义或对数据库外部任何内容的依赖的负担。例如，可以安全地重新分配代理键值，或者可以重构或丢弃键，而不会对系统用户产生任何后果。
通常，代理键对用户隐藏，以便他们不会获得任何此类外部依赖项。事实上，对用户隐藏是 EFCodd 提出的代理键原始定义的一部分。如果键值驻留在用户的浏览器缓存或收藏夹列表中，那么它们就不再用作“代理”了。因此，这就是为什么您会看到一个键仅在数据库内部使用，而同一个表的不同键在应用程序中可见的一个常见原因。
I guess you are talking about surrogate keys here. One of the desired or supposed advantages of surrogate keys is that they aren't burdened by any external meaning or dependency on anything outside the database. So for example the surrogate key values can safely be reassigned or the key can be refactored or discarded without any consequences for users of the system.
Generally surrogate keys are kept hidden from users so that they don't acquire any such external dependencies. Being hidden from users was in fact part of the original definition of a surrogate key as proposed by E.F.Codd. If key values reside in the user's browser cache or favourites list then they aren't much use as "surrogates" any more. So that's one common reason why you will see one key used only inside the database and a different key for the same table made visible in the application.
我认为这可能取决于您正在使用的应用程序的类型。我使用的企业软件仅供我工作的公司使用，一般不向外界开放。在这种情况下，让用户看到与人员相关的记录的代理键通常至关重要，因为人员表中的信息没有唯一性。可能有两个约翰·史密斯（我们实际上有超过 1000 个）是完全不同的人。他们甚至可能有相同的营业地址并且是不同的人（例如，儿子通常以父亲的名字命名，并且在同一医疗机构工作）。因此，他们需要在表单和报告中引用代理键，以确保他们使用的是他们认为想要的记录。否则，如果他们想要研究有关在报告中看到的 John Smith 的更多详细信息，他们将如何在应用程序中查找它，而不必遍历所有 1000 个来找到正确的呢？创建假 ID 和真实 ID 一样非常耗时（我们一次导入数百万条记录），而且没有任何实际收益，因为数据在我们的公司应用程序之外不可见。
对于向公众开放的网络应用程序，我可以看到您可能不想在哪里显示此信息。
I think it may depend on the type of application you are working with. I work with Enterprise software that is only used by the company I work for and is not generally available to the outside world. In this case, it is often critical to let the user see the surrogate key for people-related records because the information in the person table has no uniqueness. There can be two John Smiths (we actually have over 1000 of them) who are genuinely different people. They may even have the same business address and be different people (Sons are often named for fathers and work in the same medical practice for instance). So they need to refer to the surrogate key on forms and in reporting to ensure they are using the record they thought they wanted. OItherwise if they wanted to research further details about the John Smith that they saw in a report, how would they look it up in the aaplication without having to go through all 1000 to find the right one? Creating a fake id as well as the real one would be time consuming (we import millions of records at a time) and for no real gain since the data would not be visible outside our comapny application.
For a web app that is open to the general public, I can see where you might not want to show this information.