4

我正试图围绕 Google AppEngine 中的实体组。我总体上理解它们，但是由于听起来一旦创建对象就无法更改关系并且我要进行大数据迁移，因此我想尝试在第一时间就正确处理。

我正在制作一个艺术网站，会员可以在其中注册为普通会员或少数非多态实体“类型”（艺术家、场地、组织、艺术家代表等）之一。例如，艺术家可以拥有艺术品，而艺术品又可以拥有其他关系（画廊、媒体等）。所有这些东西都通过引用联系起来，我知道您不需要实体组来仅仅做引用。但是，一些参考需要存在，这就是我关注实体组的原因。

来自文档：“实体组的一个好的经验法则是它们的大小应该与单个用户的数据价值差不多或更小。”

也就是说，我有几个希望是/否的问题。

问题 0：我认为您不需要实体组来进行交易。但是，由于实体组存储在大表的同一区域中，这有助于减少一致性问题和竞争条件。这是对实体组和交易的公平看法吗？

问题 1：保存子实体时，是否有任何父对象被隐式访问/保存？即，如果我使用路径成员/艺术家/艺术品设置实体组，如果我保存艺术品对象，成员和艺术家对象是否得到更新/访问？我不认为，但我只是确定。

问题 2：如果问题 1 的答案是肯定的，那么访问/更新是否只会顺着路径进行而不影响其他孩子。即，如果我更新 Artwork，则不会更新 Member 的其他 Artwork 子项。

问题 3：假设在用户注册时存在成员及其关联的帐户类型实体非常重要，并且只有用户会更新其成员和关联的帐户类型实体，那么将它们放在实体组中是否有意义?

即会员/艺术家、会员/组织、会员/场地。

同样，假设只有用户能够更新 Artwork 实体，是否也包括这些实体？注意：引用艺术作品的媒体/画廊/等可能与许多艺术作品相关，而不仅仅是用户拥有的那些（即多对多关系）。

如果它以我怀疑的方式工作（即 Q1/Q2 为“否”），那么将所有用户的位都放在一个实体组中是有意义的，因为它们都将位于 BigTable 的同一区域中。但是，将艺术品添加到实体组似乎可能违反“保持小”原则，老实说，除了在用户上传艺术品图像时节省带宽/重试之外，可能不需要在事务中。

有什么想法吗？我是否错误地接近实体组？

4

1 回答 1

2
  • 0：您确实需要实体组来处理多个实体之间的事务
  • 1：修改/访问孩子不会修改/访问父母
  • 2：不适用
  • 3：听起来很合理。我的感觉是，除非你需要它们之间的交易，否则不应该使用实体组。

出于许可目的，没有必要将艺术品作为儿童。但是，如果您需要对它们进行事务性修改（包括例如创建和删除），它可能会更好。例如：如果您删除一个帐户，您会删除用户实体，但在您删除孩子之前，您会得到 DeadlineExceeded 或服务器崩溃。现在你有一个孤立的艺术品。如果某位艺术家的作品超过 1000 幅，则必须批量删除。

祝你好运！

于 2010-01-30T03:31:42.303 回答