Допустим у меня есть две таблицы: 


Есть такие записи:


Как мне вытенуть людей, каторие нечитали книжки с именем Name2 ? Left join мне вернет человека с id=1, так как он имеет есчо запись с книжкой под названием 'Name1'.

Методом исключения:



Если не пойдет, то после закрывающей скобки допиши 'AS a'.

1. У меня около 30000 людей, и если половина из них прочитали ету книжку, то получится что в not in будет около 15000 идишников (а как слишал not in при таких количествах неочень оптимальный).

2. Да и селект :  небудет выполняться для каждого человека  ?

Это сообщение отредактировал(а) gelo86 - 28.9.2009, 19:34

M Zloxa

Перенесено из баз данных

Та же проблема с not in. Я понемаю, что может и нету другого способа. А как ви относитесь к: not in(1..15000) ?

СУБД? Например счастливые пользователи Oracle могут воспользоваться предложением MINUS...

Исползуется Oracle, но пишем на Java + Hibernate => HQL, поетому думаю MINUS в HQL непрокатит :(

Можно конечно совсем без not in, 

А СУБД внутренний селект будет виполнять толко один раз ?

Вот тут  написано про про разность и некоторые варианты его реализации...

Да, так как не зависит от внешних параметров.

boevik, 
Тогда уж лучше

disitnct раскоментировать, если пара user_id,name не уникальна.

ну и еще несколько вариаций


Веский аргумент.  

Для чего нужен: 
 ?

Вполне возможно что и этот вариант пройдет. (не совсем помню как поведет себя name = 'book1' внутри on)


В этом случае на каждую запись в таблице user выполняется внутрений select, если есть индекс то может и не страшно, а если нет, то ...


минус не все СУБД поддерживают.




совсем не верный результат вернет.

Добавлено через 8 минут и 13 секунд

показать только теx пользователей из t1 которые не присуствуют в t2

Да, виноват. Спасибо.


Если нет индекса, то будет антиджойн по хэшу и это будет производительнее нежели левый джойн по хэшу но еще и с дистинктом.

Если есть ограничение уникальности по паре (user_id,name), то дистинкт не нужен, но и индекс есть. Если мы используем индекс, то для левого джоина ли, для анти джоина ли, разницу сложно будет измерить существующими в настоящее время приборами.

как бы в общем случае, этот вариант предпочтительнее левого джойна.(для оракла)

Но далеко не факт что он предпочтительнее not in. Мне кажется весьма вероятным, что замена not in ни на left join ни на not exists ничего ТС не даст.


ТС озвучил целевую платформу.
Кстати, буде у ТС записей порядка на три-четыре поболе, я бы настаивал на том, чтобы он присмотрелся именно к этому варианту.

boevik, Вообще я повторил ошибку, которую допускаю часто. Первую часть поста я обращал тебе. Остальную часть - ТС. Опять забыл поставить обращение, прошу прощения. Я не думал тебе оппонировать, просто убрал из твоего варианта лишние скобки, какбы подтверждая его правильность..



Это сообщение отредактировал(а) Zloxa - 28.9.2009, 21:57

Zloxa, вся мега платформа ТС огрничена использованием  HQL - это диалект всеми любимого и нелюбимого ORM.
так что будь у него хоть супер пупер СУБД толку от нее НОЛЬ!

Надо б разобраться с этой байдой.. хотябы  в терминологии. Дабы впредь не вестись :(

Это сообщение отредактировал(а) Zloxa - 29.9.2009, 08:37

гугль по ключивому слову - Hibernate


  в яблочко