SQL запрос.

bleyman

Вот он :
DELETE zz FROM JournalGrades zz WHERE zz.Id NOT IN (
SELECT jg.Id From
(
JournalGrades jg
INNER JOIN
JournalEvents je ON jg.EventId = je.Id
INNER JOIN
StudentsToGroups s2g ON (s2g.StudentId = jg.StudentId AND je.GroupId = s2g.GroupId)
)
)
Излагаю его словами:
С одной стороны, каждому элементу таблички Students соответствует некий набор групп, в которые он входит.
С другой стороны, каждой группе соответствует набор JournalEvents, а каждому эвенту соответствует набор JournalGrades (оценок и в каждом из них лежит Id студента.
Задача состоит в том, чтобы удалить все JournalGrades, для которых студент на самом деле не входит в ту группу, которая прописана в соответствующем JournalEvent. Ну, типа, при перемещении студентов из группы в группу ручками искать всех перемещённых в коде как-то ломает.
Внутренний селект выбирает все правильные JournalGrades, а DELETE удаляет все JournalGrades, не входящие в это множество.
Собственно, вопрос вот какой: а не будет ли это всё чудовищно тормозить из-за NOT IN (когда правильных оценок будет наццать мегабайт)? И если будет, то как сформулировать то что я хочу без NOT IN?
Я пытался экспериментировать с OUTER JOIN, успехов не поимел.
База - mssql.

bastii

Покажи план. Что, mssql не рюхнул? Может что-то с индексацией? А то по идее может быть неплохая реализация: in через внешний джоин и фильтацией на нуль, при этом разве нельзя сделать, чтобы джоин делался мерджем: скажем JournalGrades кластерный индекс по id, а во внутреннем запросе сорт по id выходил, по идее сорт должен получаться.
Или тебе хочется большего?

bastii

С другой стороны 4 джоина, mssql довольно неплохо сам рюхает, главное хорошо подумать какие индексы нужны.

bleyman

А как посмотреть план?
Все Id - праймари ключи (автоматически индексируемые то есть у StudentsToGroups всего два поля - StudentId и GroupId, которые тоже являются праймари ключом.

bastii

План смотреть в Query Analyzer.
В StudentsToGroups важен порядок полей в индексе: (GroupId, StudentId)
Тогда по идее возможен план, когда джоны во внутреннем запросе реализуются нестед лупами, а внешний джойн (тот что вместо ИН) будет мерджем. ИМХО эффективней нельзя, да и куда там, фактически О(#JournalGrades).

otvertka07

вот ссылка про план
http://www.softpoint.ru/article.php?id=17

bastii

Ну что там с планом, как теория на практике?
P.S. План нужно смотреть на реальных данных, а то на простых запросах оптимизатор халтурит.
Оставить комментарий
Имя или ник:
Комментарий: