私は最近、DB クエリの結合がどのように速度を低下させるかについてよく読んでいます。明らかに、Google App Engine はそれらを許可していません。
しかし、結合のないアプリをどのように設計するのか疑問に思っています。たとえば、私はcontactsとを持つアプリに取り組んでいorganizationsます。連絡先は多くの組織に属することができ、組織は多くの連絡先を持つことができます。2 つのエンティティを接続する 3 番目のテーブルがなければ、どのようにその関係を持つことができるでしょうか...
contacts --< contacts_organizations >-- organizations
GAE では多対多の関係を持てないということですか? 参加が必要な機能を除外しているだけですか?
各連絡先の組織 ID をスペースで区切ったリストを含むテーブルに TEXTorganizations列を作成できると思います。contactsそれは少し奇妙に思えますが。
これは、アプリケーションコードの速度低下ソフトウェアで書き込みループをアサートするのが神話であるのと同じように、速度低下ソフトウェアに加わる神話です。
つまり、なぜループを書くのですか？これは、同じコード行を何度も実行するだけです。一度では足りませんでしたか？それは途方もない無駄です！
上記の記述は皮肉なことを意図しています。
私のポイントは、クエリには、正しい答えを得るという目的のための結合が含まれているということです。もちろん、結合を非効率的または不必要に使用することは、ループ不変コードをループ内に配置するなど、設計が不十分です。
一般的なポリシーとして結合を回避することは、時期尚早の最適化の例です。効率的なコードを作成するためのアプローチがそのような包括的なルールを考え出すことである場合、結合を回避することは役に立ちません。
Google App Engineに関しては、エンティティ間の関係をサポートしますが、厳密にはリレーショナルデータベースモデルではないため、結合の概念は実際には思い浮かびません。代わりに、特定の参照から関連エンティティを取得できます。これは、モデルへのORMインターフェイスに似ており、SQLの結合と同じではありません。
詳細については、 http：//code.google.com/appengine/articles/modeling.htmlをご覧 ください。
（そのリンクはこのスレッドの別の回答にありましたが、削除されました）
重要なポイント: Google は、ユーザーが「高価な」クエリを実行するのを防ぐために、データベースでの JOIN を禁止していません。データベースはリレーショナルではないため、そもそも "JOIN" SQL 動詞は実際には適用されません。
このように、BigTable はAmazon の SimpleDBと同じです。データは非正規化され、スキーマが取り除かれるため、バケットで任意のデータを許可された巨大で効率的なハッシュ テーブルが効果的に作成されます。
これらのハッシュ テーブルは、特にリレーショナル データベースと比較して、非常に簡単にスケーリングできます。GAE のようなアプリケーションでは、完全な機能セットよりも極端なスケーラビリティが優先されます。
を使用しdb.ReferencePropertyてオブジェクトをリンクします。詳細と例については、Google App Engine: 1 対多の JOINを参照してください。
通常、結合を許可しないデータベースについて話しているときは、必ずしも 1 つのサーバーに収まらない非常に大きなデータベースについて話していることになります。最近の例は、 Amazon の SimpleDB、Microsoft の SQL Data Services、Google の App Engine Datastoreなどのクラウド データベースです。結合機能が制限されているものもありますが、大きな問題は「パーティション」をまたいで結合することです。このような大規模なデータベースでは、同じサーバーに存在する必要がないようにデータを分割します。それを分割する正しい方法を決定する必要があります。
あなたの例では、連絡先テーブルのフィールドに組織キーのリストを保存し、その逆も同様です。これらのデータベースの設計は、通常の正規化されたデータベースとは異なります。テーブルは通常「スパース テーブル」です。これは基本的に、各レコードが基本的に名前と値のペアである任意の数のフィールドを持つことができることを意味します。Amazon の商品テーブルを考えてみてください。さまざまな種類の商品に対していくつの異なるフィールドが存在する可能性があるでしょうか。本にはページ数がありますが、MP3 には再生時間があります。スパース テーブルでは、これらのレコードは同じテーブルに格納されます。
Google は計算量の多いメカニズムを引き裂いていると思うので、他の種類のリソースをより多く利用する方法を探す必要があります。たとえば、参照テーブルを維持したりテーブルをカウントしたりするハードディスクではなく、結合や集計に無駄な CPU サイクルを使用する必要があります。計算。
不可能ではありません。他の種類のリソースを使用して回避する必要があるだけです。
各テーブルから結果を個別に取得してから結合することにより、DB サーバーの代わりにアプリケーションで結合を実行できます。 1。
しかし: 正直なところ、結合は問題ではありません。彼らがそうなる頃には、この質問をする必要さえなくなるでしょう。この時点に到達する実際のプロジェクトの数を指で数えることができます (主に Ebay)。結合を完全に排除することが、これらのプロジェクトをスケーリングする唯一の方法であったという証拠はありません。
あなたが言及したデータベースは、せいぜい、複数のサーバーにまたがる非常に大量のデータを格納するように設計された、バージョン管理されたレコード ストアです。それらを「データベース」と呼ぶのは無理があります。は、結合、ACID トランザクション、ロールバックなどをサポートしていません。これらを使用せずにアプリケーションを作成することはできますが、多くの場合、機能を提供するためにさらに多くの作業を行う必要があります。
為に：
contacts --< contacts_organizations >-- organizations
連絡先に組織を非標準化し、組織に連絡先を保存できます。ただし、両方のテーブルを同時に更新するアプリケーションでは、参照整合性を強制する必要があります。
より良い解決策は、データを 3 つのテーブルに格納し、自分で「結合」を行うことです。