このケースを説明するために、例から始めることをお勧めします。Userクラスがあり、リストが必要だとしますPost。
最初に考えたのは、クラス内にこのリストを作成することですUserが、ユースケースを分析すると、ほとんどの場合、投稿なしでユーザーを取得し、ユーザーなしで投稿を取得したいことがわかります。ただし、投稿を取得するにはユーザーIDが必要です。したがって、データモデルを作成する別の方法は、関連付けを持たずにIDでPostインデックスを作成することです。User
コストの観点から、両方の実装の長所と短所は何ですか？
請求ページ、特にデータストア操作のセクションを参照してください。
https://developers.google.com/appengine/docs/billing
データストアの読み取りコストは、エンティティごとに増加します。データストアの書き込みコストは、インデックス付きのプロパティごとに増加します。
最初の方法は、1つのユーザーエンティティでのみ動作し、インデックス作成が必要ないため、はるかに安価になります。
ただし、コストが唯一の決定要因ではない可能性があります。エンティティはそれぞれ1MBに制限されているため、ユーザーエンティティ内に投稿を保存していると、壁にぶつかる可能性があります。エンティティの読み取り/書き込み時間もサイズに依存するため、エンティティが大きいと読み取り/書き込みに時間がかかります。
私の以前の答えは、ユーザーエンティティ内にPostオブジェクトのリストを実際に保存していると仮定していました。ユーザーと投稿の両方がエンティティであり、ユーザーが投稿のキーのリストを保存しているかどうかを尋ねているようです。
最初のケース（投稿エンティティへのキーのリストを持つユーザー）の主な利点は、一貫した方法で投稿を取得できることです。Userオブジェクトを取得した後、POSTSのリストを読み取り、それらを個別にフェッチできます。データストアのキーごとの操作には一貫性があります。get操作の発行方法によっては、これはクエリよりも遅くなる場合があります（つまり、forループを使用するだけの場合）。
他の非常に小さな利点があります。ユーザーの投稿リストにインデックスを付けない限り、この方法で比較的安価にユーザーを更新できます。極端な例として、ユーザーが一度に5つの投稿を追加した場合、それらすべてをリストに追加してから、1回の書き込み操作でユーザーに1回書き込むことができます。とにかくPostエンティティを作成する必要があるため、これはそれほど素晴らしいことではありませんが、エンティティごとのインデックス書き込み操作が1つ少なくなります。
ユーザーエンティティのサイズにはまだ制限があるため、リストには最大の制限があります。エンティティごとのインデックスエントリの数にも最大値があるため、リストにインデックスを付けると、制限になる可能性があります（ただし、ユーザーエンティティの作成コストも高くなります）。
読み取りの観点から、最初のケースは最適ではありません。
2番目のケースは、読み取りの観点からより適切に機能します。ユーザーIDがある場合は投稿を取得しやすくなりますが、投稿を書き込むときにインデックス書き込み操作があります。投稿を頻繁に作成しない場合は、これが適しています。クエリは常に一貫していることに注意してください。