我开始在谷歌应用引擎中开发一个应用程序作为我的第三年项目。我没有太多的数据库练习和JPA。
我只是想知道使用Key for Id之类的东西是什么原因。
无论如何它会在数据库中，为什么不使用它呢？
我们可以声明一个ID
@Id private Key id
或
@Id private long Id
等
但是，无论如何，Key都会被分配给GAE中的任何实体，那么为什么还要将其他东西作为ID来分配呢？
还有其他问题，尤其是关系。例如，如果部门的Id是长的，那么用户（部门的孩子）也可以拥有一个很长的ID吗？
NO。为什么呢？
数据存储区必须存储子项中父子关系的引用。因此，它需要有一个字段，它是子节点中的Id，它可以存储父节点的Long值。
可能是我要问的是为什么有人会使用String，long等等的传统原因是什么？为什么你仍然希望Id尽可能长或字符串甚至存在关键类
答案 0 :(得分：0)
有时没有可用的密钥。例如，考虑日志。日志通常会复制所有字段，包括日期和时间，并且没有唯一列。
编辑 - 决定什么成为关键取决于存储的数据。如果有唯一字段，请使用它。如果没有唯一字段，请让数据存储生成一个。
考虑基于GAE的数据记录应用程序。客户端可以发布要记录的记录，包括到最近的秒的时间和客户端名称。 AppEngine将在同一秒内接受来自同一客户端的多条记录，但每条记录仍必须具有唯一标识符。这就是我所说的日志中的重复记录（我恰好正在开发这样一个GAE项目）。例如，故障可能会快速连续记录许多相同的错误消息。
转到您添加的问题，其他应用程序通常可以提供每个记录唯一的字段，因为stevep也有助于指出。对于您的软件和最终用户来说，使用该唯一字段几乎总是比GAE可以选择生成的唯一标识符更方便。这里的示例是您可以设计一个基于GAE的站点，该站点将您的StackOverflow帐户称为Nomad或用户3194545.该名称比生成的Id编号更令人难忘。不要担心StackOverflow是否在GAE上运行，它可以但不是重点，这是一个例子。
关于您的下一个问题，如果部门的ID很长，则用户（部门的孩子）也可以拥有较长的ID。即使是相同的值，因为这两个标识符在不同的范围内使用。
既然你说你是新手，那就彻底研究Entities, Properties, and Keys。不要混淆Id和Key。您可以指定Id或让Datastore执行此操作。如果选择指定Id，则可以使用String或长整数。数据存储创建每个Key，这是一个更复杂的数据。谷歌为开发商提供替代品的原因是因为许多开发商想要替无论您使用JPA，JDO还是低级数据存储API，概念都是相同的。
答案 1 :(得分：0)
Key现在是一个long int，可能会导致Javascript出现问题。因人而异。这是一个问题，当GAE几个月前做出改变时，这就是为什么你可以选择更短的int键，如果你想要它。除此之外，IMHO经常需要根据您可以使用客户端逻辑构建的内容来定义唯一键。如果可以，为什么不这样做呢？您可以越多地依赖客户端ID来进行get_by_key查找，您就越好。使用GAE，应该始终向客户端寻找通过密钥名称而不是通过查询数据库以获取ID来请求实体的方法。同样，所有这些设计建议都是恕我直言，所以坚持其他方法的纯粹主义者（例如总是使用本地分配的ID值）可以自由地区别开来。