1

UserId (文字列) とRSSSubscriptions (文字列)の 2 つのプロパティを持つエンティティがあります。このクラスのインスタンスは App Engine Datastore に保存されます。

RSSSubscriptionsは、のようなキーと値のペアにする必要があります"Site1: Feed1", "Site2: Feed2".

ハッシュマップのようなデータ型は永続化できないため、このデータを String 形式で保持する必要があります。現在、JSONArray形式の文字列型として保存しています。と言う"[{"Site1: Feed1"}, {"Site2: Feed2"}]"

私のクライアントは Android アプリになります。したがって、クライアント側でこの文字列を JSON 配列として解析することになっています。しかし、ユーザーが新しいサブスクリプションを追加するたびに、JSON 形式で文字列を作成し、既存の文字列を追加するのは悪い考えだと思います。より良いアイデアはありますか?

4

2 に答える 2

1

その特定の理由でndbによってサポートされているJSONPropertyを使用できます。私の意見では、Jsonを文字列として保存し、前後に解析するための「毛深い」ソリューションです。有効性を保証するために非常に注意する必要があります。

于 2012-12-14T10:28:41.673 に答える
0

正解はいくつかの要因に依存し、予想されるペアの数が最も重要です。クエリによってアクセスされるエンティティにペアを格納するには、かなりのコストがかかることに注意してください。クエリを実行するための多数の操作コストがあり、かなりの CPU 時間が発生します。これを、ユーザー ID をキーとする単一のレコードを使用し、TextProperty 内に JSON を格納する場合と比較してください。これは 1 つの小さな操作コストと CPU 時間であり、おそらくクエリの 10 分の 1 になります。

エンティティをクエリするという技術的によりクリーンなアプローチを採用することを決定する際は、これらの要因を考慮してください。私自身、削除率が非常に高い場合を除いて、「数千のペア」ボリューム内のものには、常に TextProperty 内のシリアル化された文字列を使用します (これでも、文字列アプローチの方が優れている可能性があります)。クエリの使用は、リソース コストが高いことを考えると、一般に GAE の最後の設計選択です。

于 2012-12-13T16:36:48.030 に答える