私は、ユーザーが単純な Web サイトを作成して静的 Web ホストに公開できるようにする Web アプリケーションに取り組んでいます。必要と回避の間の灰色の領域で祖先を使用するかどうか、およびどのように使用するかを決定するのに問題があります。
モデルはかなり単純です。現在、everyUserには 1 つ以上のWebsiteエンティティがあります。エンティティにはWebsite、Web サイトに関するすべての基本情報と、Pageエンティティを参照するネストされたナビゲーション メニューが格納されます (ナビゲーション ツリーは JSON プロパティとして格納されます)。エンティティ タイプはPagePolyModel に基づいており、異なる動作をするページ タイプがいくつかあります (GalleryPageたとえば、 があります)。
エンティティ グループはまだありません (というか、祖先を持つエンティティはありません)。必要なトランザクションは 2 つだけです。たとえば、ページの名前を更新する場合、Pageエンティティ自体だけでなく、エンティティのナビゲーション ツリーでも更新する必要がありWebsiteます。
エンティティ グループがどのように機能するか、およびそれらを使用することの基本的な意味は理解していると思いますが、どちらのアプローチにも明確な理由がない場合、データを構造化するための "最善の" 方法を決定するのに苦労しています。私はできた：
私のエンティティの祖先を完全に削除します。私が理解している限り、エンティティをキーで取得し、トランザクション内で5つ以上を必要としない限り、クロスグループトランザクションを引き続き使用できます。マイナス面は、XG トランザクションに依存することであり、祖先クエリを使用して忍び寄ることができなくなるポイントが来る可能性があることです (そして、手遅れになる可能性があります)。
ユーザー オブジェクトを、すべての Web サイト、ページ、およびその他のデータの親にします。これにより、ユーザーはすべてのデータの一貫性のあるビューを得ることができ、トランザクションを必要とする機能を追加するたびにトランザクションを使用できるようになりますが、継続的な書き込みは 1 ～ 5/秒に制限されます。ただし、ユーザーは自分のデータのみを更新するため、これは実際には機能し、1000 人のユーザーでも 1 人の場合とまったく同じように動作する可能性があります。
さらに小さなエンティティ グループを使用するようにしてください (ナビゲーションを から分離し、
Websiteそれを Web サイトのページの親にするなど)。しかし、ほとんどの編集は Pages で行われるため、これに大きなメリットがあるかどうかはよくわかりません。
本当の問題は、App Engine で祖先リレーションシップを使用する明確な理由がない場合、どのような場合にそれを使用するかをどのように決定するかということだと思います。強力に一貫性のあるクエリと、後で機能を追加するときにトランザクションを自由に使用できるという利便性を求めますか?それとも、後でトランザクションを実行する能力を制限する可能性があるとしても、非常に明白な理由があるまで、それらを絶対に避けますか?
関連ドキュメントを読み、「Programming App Engine」のトランザクションに関する章を読み、かなりの数の Google I/O ビデオを見ましたが、それでもその決定を下すのは難しいと感じています。