Google App Engineで、最も効果的な多対多の結合モデルは何ですか？

BigTableのデザインは、明示的に小さなテーブルの大きなホストへの非正規化を好む、標準のリレーショナルモデルの哲学の多くを拒否します。

これが問題となる大きな領域の1つは、多対多の結合のモデリングです。

これらの結合をモデル化する1つの方法は、最初の正規形に違反し、すべての興味深いデータをdb.ListProperty（）に置くことです。これはクエリから検索可能ですが、リストの検索と別のテーブルのプルのパフォーマンスへの影響についてはまだ調べていません。

結合はできないため、RelationshipPropertiesを介してテーブルをリンクすることができます。したがって、十分な労力をかけて、標準の交差テーブル（両方の親テーブルを参照する結合主キーを持つテーブル）を作成できます。さまざまな実装のパフォーマンスへの影響を調査した人はいますか？

-編集-

ドキュメントで提案されているキーのリストは確かにそれを行う1つの方法ですが、私はそのパフォーマンスと他の実装の異常率に興味があります。キーの相互リストを作成するのにユーティリティはありますか？繰り返しに伴う努力はその代価に見合うものですか？それを行うより良い方法はありますか？

私は現在GAEデータストアも使用しています。まだ行っていない場合は、この記事を確認してください。何か便利なものを見つけたら、質問を更新してください。

編集：

今日これを見つけました、チェックしてください。

私のGAEの経験では、テーブルクエリは慎重に使用する必要があります。「結合」テーブルを追加すると、さらに遅くなります。たとえば、多対多のリレーションシップを共有するテーブルAとBがあり、AとBの両方に対してRelationshipPropertyフィールドを持つ「結合」テーブルJを作成する場合、検索するたびにJをクエリする必要があります。関連レコード（エンティティ）。

キーのリストをAまたはB（または必要に応じて両方）に含めると、レコード/エンティティをフェッチするときにキーのリストが含まれるため、はるかに高速になります。リストにキーが多すぎない限り（つまり、エンティティが大きすぎない限り）、この方法が適しています。

アプリケーションでndbを使い始めましたが、エンティティをフェッチするときにキーを使用することにはいくつかの大きな利点があります。エンティティがすでにキャッシュされている場合は、最初にメモリまたはmemcacheからエンティティをプルします。したがって、キーのリストに大きな重複がある場合、すでにフェッチされたエンティティのフェッチははるかに速くなります。