リレーショナル思考から抜け出そうとするのは良い仕事です。行/テーブルの考え方から離れるのは良いことです。
少なくともプログラミング側では、エンティティをリモートに格納されたデータ構造またはクラス インスタンスと見なすことで、さらに近似することができます。これらのエンティティにはプロパティがあります。エンティティとは別にインデックスがあります。インデックスは、基本的にプロパティの特定の基準に一致するエンティティのリストを格納します。
エンティティを書き込むと、データストアはメモリ/ストレージ内のそのインスタンスを更新してから、すべてのインデックスを更新します。
クエリを実行するときは、基本的にインデックス リストの 1 つを調べます。
これにより、データストアについて考えるための基本的なフレームワークが得られます。
データストアを設計するときは、通常、コストを考慮して設計する必要があり、程度は低くなりますがパフォーマンスも考慮する必要があります。書き込み側では、インデックスの数を最小限に抑えたいと考えています。読み取り側では、読み取るエンティティの数を最小限に抑える必要があるため、赤、青、緑に個別のエンティティを用意するという考えは悪い考えであり、常に数を読み取る必要がある場合は読み取りコストが 3 倍になります。赤/青/緑の車。これが理にかなっている、非常にあいまいなコーナーケースがいくつかある可能性があります。
設計上の考慮事項は、通常、次のようにする必要があります。
- どのような種類のクエリを実行する必要がありますか?
- これらのクエリを簡単に実行できるようにデータを構造化するにはどうすればよいですか (GAE クエリ機能が制限されているため)。何らかの形でデータを複製すれば、クエリはより簡単になりますか?また、この複製されたデータを自分で維持することはできますか?
- エンティティを更新するときに、更新が必要なインデックスの数を最小限に抑えるにはどうすればよいですか?
- 完全な一貫性が必要なため、一貫したクエリを作成できるように構造を調整する必要がある特別なケースはありますか?
- 注意が必要な書き込みパフォーマンスのケースはありますか。
どのような種類のクエリを作成しようとしているのか正確にわからない場合、この答えは正しくない可能性がありますが、これをどのように考えたいかを説明する必要があります。
人々が自分の車を登録するアプリケーションがあり、データストアをポーリングして各色の車の数を表示するダッシュボードがあると仮定します。色とカウント属性を持つ Car クラスを持つ従来のメカニズムは依然として理にかなっています。インデックス付きプロパティの数が最小限に抑えられるため、書き込みコストが削減されます。
これはちょっと変わった例です。カウントを追跡する単一のエンティティだけが必要かどうかはわかりません (この場合、クエリを実行する必要さえなく、そのカウントを取得するだけで済みます)。 ）、またはフェッチして合計できるカウントのエンティティが多数ある場合。
ただし、ユーザーの更新によって同じエンティティが変更されると、パフォーマンスの問題が発生する可能性があります。https ://developers.google.com/appengine/articles/sharding_counters をよくお読みください。