0

詳細

  1. Aには sPersonがたくさんありObjectiveます。
  2. ObjectivePersonには、 に関する固有の詳細がありActivityます。
  3. Activityには、世界記録などの一般的な情報が含まれています。
  4. Personを組織してEventを試みることができObjectiveます。
  5. Aは他の をと一緒に を視聴するようにPerson招待します。PersonEventInvitation

スキーマ

注: スキーマ ダイアグラムの例には、"(fk)" で示されている backref のみがリストされています。矢印は通常の関係を意味します。

イメージタグを使用するための10ポイントを取得するまでのイメージリンク

質問

受け取ったすべての のほとんどEventの 、Objective、およびActivity詳細(ステータスに関係なく、ステータスはまだ必要です) を一度に表示したいです。InvitationPerson

このような JOIN に取り組む前に、問題を表現するより良い方法はありますか? Person-> Invitation<-EventはAssociation Objectパターンだと思いますが、返されたそれぞれについてクリーンで効率的な方法で and の情報をObjective取得する方法がわかりません。ActivityInvitation

おまけ: サンプルの SQLAlchemy クエリを提供します。

4

1 に答える 1

1

SQL 側では、これは非常に簡単です。1 つの ID 番号 (人用) のみを使用して、テスト用にいくつかのテーブルを作成しました。残りのキーはすべて自然キーでした。このクエリの実行計画を見る

select I.*, A.activity_placeholder, E.event_location, O.objective_placeholder
from event_invitations I
inner join activity A 
        on (I.activity_name = A.activity_name)
inner join events E 
        on (I.personal_id = E.personal_id 
        and I.activity_name = E.activity_name
        and I.objective_deadline = E.objective_deadline
        and I.event_time = E.event_time)
inner join personal_objectives O 
        on (I.personal_id = O.personal_id
    and  I.activity_name = O.activity_name
    and  I.objective_deadline = O.objective_deadline)
where I.person_invited_id = 2;

event_invitations のシーケンシャル スキャンを除いて、dbms (PostgreSQL) がインデックスを使用していることを示しています。これは、使用したデータが非常に少ないためだと確信しているため、これらのテーブルはすべて RAM に簡単に収まります。(テーブルが RAM に収まる場合は、多くの場合、インデックスを使用するよりも小さなテーブルをスキャンする方が高速です。)

オプティマイザーは、クエリの各部分のコストを 0.00 と見積もっており、それを超えることはありません。実際の実行時間は 0.2 ミリ秒未満でしたが、それはあまり意味がありません。

これをSQLAlchemyに翻訳できると確信しています。私のテーブルとサンプル データを投稿してほしい場合はお知らせください。

于 2011-02-13T14:07:30.407 に答える