GoogleAppEngineのエンティティグループに頭を悩ませようとしています。一般的には理解していますが、オブジェクトが作成されると関係を変更できないようで、ビッグデータの移行が必要なため、最初から正しく設定するようにしたいと思います。
私は、メンバーが通常のメンバーとして、または少数の非多形エンティティの「タイプ」（Artist、Venue、Organization、ArtistRepresentativeなど）の1つとしてサインアップできるArtサイトを作成しています。たとえば、アーティストはアートワークを持つことができ、アートワークは他の関係（ギャラリー、メディアなど）を持つことができます。これらはすべて参照を介して接続されており、単に参照を行うためにエンティティグループは必要ないことを理解しています。ただし、いくつかの参照が存在する必要があるため、エンティティグループを調べています。
ドキュメントから：「エンティティグループの経験則として、1人のユーザーに相当するデータのサイズ以下にする必要があります。」
そうは言っても、はい/いいえの質問がいくつかあります。
質問0：トランザクションを実行するためだけにエンティティグループは必要ないようです。ただし、エンティティグループはBig Tableの同じ領域に保存されるため、一貫性の問題と競合状態を減らすのに役立ちます。これは、エンティティグループとトランザクションを一緒に公正に見ていますか？
質問1：子エンティティが保存されると、親オブジェクトは暗黙的にアクセス/保存されますか？つまり、パスMember / Artist / Artworkを使用してエンティティグループを設定した場合、Artworkオブジェクトを保存すると、MemberオブジェクトとArtistオブジェクトが更新/アクセスされますか？私はそうは思わないでしょうが、私はただ確認しているだけです。
質問2：質問1の答えが「はい」の場合、アクセス/更新はパスをたどるだけで、他の子供には影響しませんか。つまり、アートワークを更新しても、メンバーの他のアートワークの子は更新されません。
質問3：ユーザーがサインアップするときにメンバーとそれに関連するアカウントタイプのエンティティが存在し、ユーザーのみがそのメンバーと関連するアカウントタイプのエンティティを更新することが非常に重要であると仮定すると、これらをエンティティグループにまとめることは理にかなっていますか？ ？
すなわち、メンバー/アーティスト、メンバー/組織、メンバー/会場。
同様に、ユーザーだけがアートワークエンティティを更新できると仮定すると、それらも含めるのは理にかなっていますか？注：アートワークへの参照であるメディア/ギャラリーなどは、ユーザーが所有するものだけでなく、多くのアートワークに関連している可能性があります（つまり、多対多の関係）。
すべてのユーザーのビットがBigTableの同じ領域にあるため、私が思うように機能する場合（つまり、Q1 / Q2は「いいえ」）、エンティティグループにすべてのユーザーのビットを含めることは理にかなっています。ただし、アートワークをエンティティグループに追加すると、「小さく保つ」という原則に違反する可能性があり、正直なところ、ユーザーがアートワーク画像をアップロードするときに帯域幅/再試行を節約する以外に、トランザクションに含める必要がない場合があります。
何かご意見は？エンティティグループへのアプローチが間違っていますか？