Эффективный запрос на расширенные детали от шаблона объекта ассоциации - PullRequest
Новая
       10

Эффективный запрос на расширенные детали от шаблона объекта ассоциации

0 голосов
/ 25 ноября 2010

Подробности

  1. A Person имеет много Objective s.
  2. Objective s имеют Person -специфические сведения о Activity s.
  3. Activity содержит общую информацию, такую ​​как мировой рекорд.
  4. A Person может организовать Event для попытки Objective.
  5. A Person приглашенийдругие Person s для просмотра Event с Invitation.

Схема

Примечание: только примерные ссылки перечислены на диаграмме схемы примера, обозначенной как"(ФК)".Стрелки означают нормальное соотношение.

Ссылка на изображение, пока я не получу 10 баллов за использование Тег изображения

Вопрос

Я хочу больше всего Event, Objective и Activity подробности для всех Invitation с одного Person полученного (независимо от статуса , но статус по-прежнему необходим), отображаемого сразу.

Есть ли лучший способ представить проблему, прежде чем я попытаюсь заняться этим как JOIN?Я считаю, что Person -> Invitation <- <code>Event является шаблоном Association Object , но я не уверен, как получить информацию Objective и Activity в чистом, эффективномспособ для каждого Invitation возвращено.

Бонус : предоставить пример запроса SQLAlchemy.

1 Ответ

1 голос
/ 13 февраля 2011

На стороне SQL это довольно просто. Я построил несколько таблиц для тестирования, используя только один идентификационный номер (для лиц); все остальные ключи были естественными ключами. Просмотр плана выполнения для этого запроса 

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;

показывает, что dbms (PostgreSQL) использует индексы повсюду, за исключением последовательного сканирования event_invitations. Я уверен, что это потому, что я использовал очень мало данных, поэтому все эти таблицы легко помещаются в оперативную память. (Когда таблицы помещаются в ОЗУ, часто быстрее сканировать небольшую таблицу, чем использовать индекс.)

Оптимизатор оценивает стоимость каждой части запроса в 0,00, и вы не можете получить намного лучше, чем это. Фактическое время выполнения составило менее 0,2 миллисекунды, но это мало что значит.

Я уверен, что вы можете перевести это на SQLAlchemy. Дайте мне знать, если вы хотите, чтобы я опубликовал свои таблицы и образцы данных.

...