Google app engine 避免应用程序引擎中不必要的大ID

最近，我们决定，如果我们的数据存储实体的ID不是那么大的话，这将对我们有利。最大的原因是，我们在URL中使用这些ID，我们希望保持简洁

例如，目前我们实体的ID增长如下：

id=2
id=2003
id=2004
id=2027
id=2028
id=5002
id=5204
id=6001
id=7534
id=8001
id=10192
id=11306
id=14306
id=16330
id=18306
id=20321
id=41312
id=79306
id=113308
id=113311
etc.

正如你所看到的，有时增长是在数万

现在，我们可以通过创建一个切分计数器来处理所有这些麻烦，该计数器足够大，可以为我们计算实体的数量，然后自己分配ID，但我还是希望数据存储能够为我们分配密钥

有没有办法告诉数据存储重新计算可用ID，以便下次我存储实体时，它将获得最低的可用ID？在我们的案例中，它们不需要是连续的

更新：

正如@所建议的，我们可以将数字编码到base62以缩短它们（对于64位无符号

int

s，最多11位）

虽然这种方法还不错，但也有一些缺点。首先，我不确定它有多好。其次，一些数字会与我们当前在URL中使用的其他字符串冲突

例如：

/books/(\d+)(/book-name)?
/books/selection

---

id为26086738530的书将有URL“/books/selection/book name”和“/books/selection”，与我们的另一页冲突。

恐怕数据存储中没有允许您控制自动id创建的机制

您估计在项目生命周期中将有多少个对象？因为长ID现在看起来很麻烦，但在商店中有成千上万个对象时，它可能是一个必要的工具

---

与base62一样，您可以通过不同的url路由base62 ID。

在url中使用ID时，为什么不在更紧凑的基础上重新编码ID？（例如base-62）@我已经更新了问题，以显示base62的问题所在。在您显示的示例中，没有冲突，如果url的正则表达式类似于/books/selection/*@是的，它是：base62（26086738530）=“selection”，并且由于“/book name”部分是可选的，它“/books/selection”将与书中的页面相对应。@AttilaOláh避免这种情况的唯一方法是构造URL方案，使其明确无误。好的，没错。我会考虑你的建议，但是我认为我们现在不会使用Base64——如果我们只想缩短URL，我们可以使用一个公共URL缩短器……如果你决定使用公共URL缩短器，你可以尝试使用BIT.LY，它允许你缩短URL并且拥有你自己的域名（免费）。