Database design 数据库中唯一的整数计数器

假设我想在数据库中构建一些小部件。构建过程开始，get是一个唯一的ID，开始工作一段时间，然后当它完成时，在数据库中以给定的ID写入数据。有许多类型的小部件，并且ID在所有小部件中都应该是唯一的

如果我在Postgres中这样做，我可能会有一个主

小部件

表，每个小部件类型都有一个表（

小部件x

，

小部件y

，等等）继承自主表。ID将是主

小部件

表上的串行类型。当构建过程开始时，我会插入一些数据，获取我的唯一ID，开始工作，当构建完成时更新表。我可能不会在整个过程中使用事务，因为构建过程可能需要很长时间

一个人怎样才能做到这一点呢？我真的需要ID是一个递增的整数，所以我不能使用默认的UUID键。我希望每个小部件类型都在它自己的表中

如果我在每个小部件构建开始之前执行此查询：

r.table("counters")
    .get("some-uuid-key")
    .update({ widget_counter: r.row("widget_counter").add(1) }, {return_vals: true})

这会像我希望的那样工作吗，给我一个数据库范围的唯一ID，而不存在任何ID冲突的可能性

---

谢谢…

你所拥有的将起作用，并且与我所认为的那个问题的规范解决方案一样接近。全局唯一的递增ID在集群环境中或多或少是不可能的，这就是为什么默认情况下我们没有将它们作为选项的原因。这里的工作原理是，每个请求都必须经过一台机器才能获得其id（《代码》）计数器的主机器table。这有一个缺点，即如果该机器死机，则需要获取id的每个查询都将开始失败。

在数据库中有一个计数器表可以保证顺序，但代价是更好的HA（高可用性）

如果您不需要绝对增量数字，只需要为公开的记录选择一个短整数，您还可以设置一组票证服务器。每个票证服务器每N个数字发送一次。您将获得冗余和较低的数字，但无法保证顺序，并且随着时间的推移，可能会有显著的漂移。我认为对于这样一个系统，每个客户机还可以传递它得到的最后一个id…这样，如果漂移大于X，它可以向前跳以保持漂移处于检查状态

---

如果您有未公开的ID（例如在查询字符串上，甚至在查询字符串上），我发现UUID几乎是作为大多数类型数据库记录的密钥支持的最佳选项。

对我来说，拥有

/profile/9d1c0945-c627-4b79-a7e7-c998c0fc5d7e

太长了，最好有一个8个字符的ID。我一直在寻找一种在数据库中拥有较短ID的方法，但还没有找到一种好的方法。