假设我想在RethinkDB中构建一些小部件。构建过程开始，得到一个唯一的ID，开始工作一段时间，然后当它完成时，在给定的ID下将数据写入数据库。有许多类型的小部件，ID应该是唯一的。
如果我在Postgres中这样做，我可能会有一个主widget表，每个窗口小部件类型有一个表（widget_x，widget_y等等）继承自该主要表表。该ID将是主widget表上的SERIAL类型。当构建过程开始时，我会插入一些数据，获取我的唯一ID，开始工作，并在构建完成后更新表。我可能不会在整个过程中使用交易，因为建筑物可能需要很长时间。
如何在RethinkDB中执行此操作？我真的需要ID是一个递增的整数，所以我不能使用默认的UUID键。我希望每个小部件类型都在它自己的表中。
如果我在每个小部件构建开始之前执行此查询：
r.table("counters")
.get("some-uuid-key")
.update({ widget_counter: r.row("widget_counter").add(1) }, {return_vals: true})
我希望它会工作，给我数据库范围的唯一ID，没有任何ID冲突的可能性吗？
...谢谢
答案 0 :(得分：2)
你所拥有的东西将起作用，并且就像我认为的那样接近于解决该问题的规范解决方案。在集群环境中，全局唯一的升序ID或多或少是不可能的，这就是我们默认情况下不将它们作为选项的原因。你有什么工作，因为每一个请求都必须通过一台机器来获取它的id（"counters"表的主机。这有一个缺点，如果该机器死了每个需要获取id的查询将开始失败。
答案 1 :(得分：1)
在DB中有一个计数器表可以保证顺序，但代价是更好的HA（高可用性）。
如果您不需要绝对增量数字，只需要对公开的记录使用短整数，您也可以设置一组票证服务器...每个都给出每个第N个号码。您将获得冗余和较低的数字，但您将无法获得订单保证，并且可能会随着时间的推移而出现明显的变化。我想过这样一个系统，每个客户端也可以传递它得到的最后一个id ...这样，如果漂移大于X，它可以向前跳过以防止漂移。
如果您有未公开的ID（例如在查询字符串上，甚至那时），我发现UUID只是支持最佳的选项，是大多数类型数据库记录的关键。