GQLで何を好むか。 StringListPropertyまたはListProperty？

Question

私は多くの関係のあるアプリケーションを構築しています。エンティティの「画像」のアイテムは、任意の数のギャラリー（「ギャラリー」）にリンクできます。そしてもちろん、ギャラリーは任意の数の写真を保持できます。

したがって、ここでGoogleの提案に続いて、「ギャラリー」の外国の鍵を保持する「Picture」のリストを使用します。これはビッグテーブルアプローチです。

（古いスタイルのリレーショナルDBアプローチは、「写真」と「ギャラリー」の間にテーブル /エンティティを持つことです。）

私の質問は次のとおりです。キーを保存する際に、「写真」に「stringlistproperty」を作成する必要がありますか、それとも「listproperty（db.key）」がうまく機能しますか？

私が見る1つの理由 StringList 他の値もキーを保存することもできますが、とにかく汚れたスタイルになります。しかし、インデックスが爆発するため、Googleはエンティティで1つ以上のリストを使用しないことを提案したと確信しています。だからこれは私にバックドアを保ちます。

As for the ListProperty タイプ」鍵「値が実際にキーである場合、1つのポイントが自動検証です。

文字列をキーに変換するのは非常に簡単で、その逆であるため、リストタイプの1つがここで好む理由はありません。

パフォーマンスの問題に関しては、これをどのようにテストできるかについてはわかりませんが、これがこの決定の主な要因になるようです。

あなたの入力に興味があります。特に、誰かがこれでパフォーマンスをテストしたか、とても親切でそれをする場合。

乾杯、//ハンヌ

Answer 1

使う db.ListProperty(db.Key) キーのリストを保存するつもりなら。それらは、文字列リストで使用する文字列表現よりもコンパクトなバイナリ表現に保存されます。

リスト内の他のオブジェクトとキーを混ぜることは厄介です。エンティティに複数のリストがあることは問題ありません。同じカスタムインデックスで複数のインデックスを獲得しない限り、爆発するインデックスを引き起こすものです。

Answer 2

db.listproperty（db.key）を使用して、これは文字列よりもデータフェッチを簡単にします。ギャラリーモデルにプロパティがある場合、db.listproperty（db.key）のタイプのpic_list（db.key）が含まれています。エンティティ..画像があなたのエンティティの名前であると仮定します。次にpicture.get（// galleryobject//。pic_list）はすべての写真を取得します。