引用应用引擎数据存储实体的首选方式：通过密钥还是 ID？答案

【问题标题】：Preferred way of referencing an app engine datastore entity: by key or ID?引用应用引擎数据存储实体的首选方式：通过密钥还是 ID？
【发布时间】：2015-05-27 17:20:48
【问题描述】：

应用引擎数据存储实体可以通过其键或（字符串或整数）ID 进行引用。是否有选择其中一个的偏好？

我可以看到使用键引用使管理界面更有用（引用的实体是可点击的），但它也占用更多空间。

【问题讨论】：

标签： google-app-engine google-cloud-datastore

【解决方案1】：

在这个特定的数据库中，我总是建议使用完整路径或Key 来引用实体，因为id 可以跨实体组重复；很简单的例子：

Key('user', 1, 'post', 1)
Key('user', 2, 'post', 1)

这是完全有效的，如果您只存储帖子 ID，则无法知道该实体属于哪个用户。

正如@tx802 提到的，总体而言开发更容易，因为可以直接获取实体；即使您在客户端和服务器之间来回移动它们，也无需重新创建它们。

唯一的缺点可能是存储/带宽增加，但这只是处理“大数据”时的问题，即使这样也不太可能成为重要问题。

【讨论】：

如果您使用 Objectify 或 ndb 等 API，存储密钥还可以更清晰地获取引用的实体。

【解决方案2】：

所有实体都有一个密钥。你问的区别是你是否应该使用

Key('Parent', 'dad', 'Child', 'ali')   # Name

或

Key('Parent', 'dad', 'Child', 1)   # ID

我会尽可能使用名称。也就是说，如果您的实体具有唯一名称。在此示例中，“爸爸”只能有一个名为“阿里”的孩子。键本质上是您的主键（如果您想将其与 SQL 中的某些内容进行比较）。请注意， Key('Parent', 'dad2', 'Child', 'ali') 是一个完全不同的 Key 并且是合法的。另请注意，如果您要存储“子”实体，则数据库中不需要存在“爸爸”或“爸爸2”。

当我有无法通过名称引用或名称可能更改的实体时，我会使用 ID。实体的键不能永远改变。

我不会为键中的空间使用而烦恼。 IMO 的成本收益不会与可读性的收益相提并论。

【讨论】：

【解决方案3】：

在向用户显示信息时，我使用 ID 作为 URL 的一部分。带有键的 URL：

http://example.com/user/b3Bhdm90ZXIVCxIIRWxlY3Rpb24YgICAgIDQuwoM

比带有 ID 的 URL 丑得多：

http://example.com/user/5891733057437696

我不使用祖先，所以我没有多个 ID 的问题，尽管我认为链接中的两个 ID 仍然比一个键短。

【讨论】：

【解决方案4】：

这个问题的答案可能取决于您对迁移数据需求的期望与对用户/人的可见性之间的平衡：

如果您可能需要将根或中间祖先添加到未来，并且需要现有的参考来保持运作，你应该使用密钥（或用于客户端的网络安全密钥）。这确保现有数据继续有效。
如果您不能保证唯一的 id（例如使用递增或生成的 ID），您可能应该使用密钥。这是因为 ids（和名称）只需要在其父级中是唯一的。如果你使用例如 UUID，这不是问题。
如果您的实体是短暂的并且您想要整洁的 url，您可能只是使用 ID/名称。如果您正在通过电子邮件发送链接，或者依赖它们长期使用 SEO，您可能需要以某种方式对密钥进行编码（再次，如果您需要在实时系统中迁移数据）

根据我的经验，数据迁移是一个真正的问题，因为数据存储有一些更独特的限制（每个实体组的写入限制和每个事务的实体组限制）。这意味着您有时需要对现有数据进行重构。您是否需要批量迁移实际上取决于您最初存储关系的方式。核心问题是您无法迁移外部保存的引用（电子邮件中的 url、SEO 索引、api 端点等），因此当您对实体密钥中的祖先“路径”做出假设时，您将破坏某些用户子集的功能。

【讨论】：