随机 ID 生成器，映射与同列答案

【问题标题】：Random ID Generator, mapping vs. same-column随机 ID 生成器，映射与同列
【发布时间】：2011-01-08 17:04:59
【问题描述】：

我们希望向客户隐藏一些实体的确切 ID - 主要原因是，我们不希望客户知道数据库中有多少实体。

例如从 URL http://mydomain/user/get/27，它说这是第 27 个用户。

因此，我正在实施一个分配随机 ID（必须是唯一的）的解决方案。换句话说，我不是使用唯一的序列号，而是寻求一个唯一的非序列+随机数解决方案。

例如来自 URL，http://mydomain/user/get/8534023，实际上是第 27 个用户。

我的问题是，知道这里的一些用户可能有类似问题的经验，我应该使用映射还是将随机ID分配给主键列？

例如

如果不存在则创建表 `test` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `somethingElse` varchar(255) NOT NULL,
  主键（`id`）
)

如果不存在 `map` 则创建表 (
  `id` int(10) 无符号非空，
  /* 测试表的外键 */
  `parent` int(11) NOT NULL,
  主键（`id`），
  键`父`（`父`）
)

VS.

如果不存在则创建表 `test` (
  /* 在此处分配随机 ID */
  `id` int(10) 无符号非空，
  `somethingElse` varchar(255) NOT NULL
  主键（`id`）
)

对我来说，后者更方便，因为我不必维护映射，也不必自定义 DAO/应用程序以使用映射的 ID（或内部的确切 ID）。对于这两种情况，我都必须编写自己的随机 ID 生成器。

【问题讨论】：

标签： java sql database hibernate

【解决方案1】：

你是对的 - 后者是更好的方法。这是一对一的关系——没有理由有一个单独的表。我建议：

“假”用户 ID 上的索引，因为它将用于查找
列上的唯一约束，以确保不插入重复值

您对不公开实际主键值的担忧也是有效的。它确保如果数据库发生更改，并且实际的主键值发生更改 - 用户将不知道更改。

【讨论】：

+1 拥有“功能”键绝对是最佳实践。

【解决方案2】：

为什么不将增量种子起始值设置为 8534023 之类的值？您的第一个客户是 8534023，您的第二个客户是 8534024，依此类推。您的客户永远不会知道这意味着什么，但您会。

【讨论】：

数据库之间的迁移存在不同键值的风险 - 拥有代理键将使用户永远不会知道发生了更改。
但仍然是连续的；所以你还在泄露年表信息。