我正试图围绕Google AppEngine中的实体组。我一般都理解它们，但是因为一旦创建对象听起来你不能改变关系并且我有大量的数据迁移要做，我想尝试第一次就把它弄好。
我正在建立一个艺术网站，成员可以作为常规会员或少数非多态实体“类型”（艺术家，地点，组织，艺术家代表等）之一注册。例如，艺术家可以拥有艺术作品，而艺术作品又可以有其他关系（画廊，媒体等）。所有这些都是通过参考连接的，我知道你不需要实体组来做参考。但是，一些参考文献需要存在，这就是为什么我要查看实体组。
来自文档： “对于实体组来说，一个好的经验法则是，它们的大小应该与单个用户的数据量相当或更小。”
那就是说，我有几个希望是/否的问题。
问题0：我认为您不需要实体组来进行交易。但是，由于实体组存储在Big Table的同一区域中，这有助于减少一致性问题和竞争条件。这是对公平组和交易的公平看法吗？
问题1：保存子实体时，是否隐式访问/保存了任何父对象？即如果我使用路径成员/艺术家/艺术品设置实体组，如果我保存艺术品对象，会更新/访问会员和艺术家对象吗？我想不会，但我只是确定。
问题2：如果问题1的答案是肯定的，那么访问/更新是否仅沿着路径前进而不影响其他孩子。即如果我更新艺术作品，则不会更新会员的其他艺术作品。
问题3：假设当用户注册并且只有用户将更新其成员和关联的帐户类型实体时，成员及其关联的帐户类型实体是非常重要的，将这些实体放入其中是否有意义实体组合在一起？
即。会员/艺术家，会员/组织，会员/场地。
同样，假设只有用户才能更新艺术品实体，那么包含这些实体是否有意义？注意：引用艺术品的媒体/图库/等可能与许多艺术品有关，而不仅仅是用户拥有的那些（即多对多关系）。
如果实体组中的所有用户位按照我怀疑的方式工作（即Q1 / Q2为“否”），那么它是有意义的，因为它们都将位于BigTable的相同区域中。但是，将Artwork添加到实体组似乎可能违反了“保持小”的原则，老实说，除了在用户上传图片图像时节省带宽/重试之外，可能不需要进行交易。
有什么想法？我接近实体组是错误的吗？
答案 0 :(得分：2)
出于许可目的，没有必要将作品作为儿童。但是如果你需要对它们进行事务性修改（包括例如创建和删除），那可能会更好。例如：如果删除帐户，则删除用户实体但在删除子项之前，会出现DeadlineExceeded或服务器崩溃。现在你有一个孤儿艺术品。如果您的艺术作品超过1,000件，则必须分批删除。
祝你好运！