Некоррелированная обработка

с концептуальной точки зрения внешний запрос и некоррелированный подзапрос (или внутренний запрос) реализуются за два шага. Сначала внутренний запрос возврашает идентификационные номера тех издательств, которые опубликовали книги по бизнесу (1389 и 0736):

SQL:

select pub id from titles

where type = business

Результат: pub id

~1?89 1389 0736 1389

Затем эти значения передаются на внешний запрос, который отыскивает названия издательств, соответствующие указанным идентификационным номерам в таблице publishers:

SQL:

select pub name from publishers

where pub id in (1389, 0736)

Результат: pub name

New Age Books Algodata Infosystems

Определение имен столбцов. Принадлежность столбцов в подзапросах таблицам неявно задается в их предложениях FROM. Это означает, что столбец pub id в предложении WHERE внешнего запроса принадлежит таблице из предложения FROM внешнего запроса - т.е. таблице publishers. Столбец pubid в списке выбора подзапроса принадлежит таблице, указанной в предложении FROM этого подзапроса - т.е. таблице titles.

Вот как выглядел бы этот запрос в случае явного указания принадлежности столбцов таблицам:

SQL:

select pub name from publishers where publishers.pub id in (select titles.pub id from titles

where type = business)

Вы никогда не ошибетесь, указав явно имя таблицы. Кроме того, с помощью явных определений вы всегда можете отменить неявно выраженные предположения относительно имен таблиц.

Коррелированная обработка

Коррелированные запросы хотя и не столь элегантны, зато весьма эффективны (с их помощью можно решать проблемы, не имеющие простых решений, если пользоваться объединениями или некоррелированными запросами). Пока что вам достаточно будет понять синтаксис этих запросов и получить общее представление о том, как они работают. Поэкспериментировав немного с этими запросами, вы почувствуете себя значительно увереннее.

В коррелированном подзапросе внутренний запрос не может быть реализован немедленно: он ссылается на внешний запрос и выполняется поочередно для каждой строки во внешнем запросе. В примере, представленном на рис. 8.2, внешняя таблица (publishers) имеет три строки, поэтому внутренний запрос будет выполняться трижды.

С концептуальной точки зрения обработка включает следующие этапы. Внешний запрос отыскивает первое имя в таблице publishers (допустим, New Age Books). Чтобы найти требуемые строки в таблице titles, внутренний запрос объединяет соответствующий publishers.pub Jd (0736) с titles.pubid (в результате находится шесть строк). Затем внутренний запрос возвращает этот результат в предложение IN внешнего запроса, где titles.type сравнивается со строкой business . Только одна книга из шести является книгой по бизнесу, но этого достаточно: New Age Books удовлетворяет требуемым критериям. Затем снова начинает работать подзапрос, на этот раз пользуясь pubJd второй строки из таблицы publishers (QS77). Он отыскивает еще шесть строк, причем все они относятся к различным типам книг по кулинарии; это издательство (Binnet & Hardley) не удовлетворяет указанным нами критериям. Подзапрос выполняется в третий раз с publishers.pub Jd, равным 1389 (Algodata Infosystems), и находит еще шесть строк. Три из них относятся к типу business . В результирующий список также попадет и Algodata Infosystems.

Определение имен столбцов. Коррелированные запросы требуют явного указания имен столбцов из внешнего запроса (можно пользоваться псевдонимами, например p.pubjd вместо publishers.pubid на рис. 8.2). Принадлежность таблицам столбцов во внутреннем запросе задается неявно.

Однако вы в любом случае можете указать обе таблицы:

SQL (коррелируемый):

select pub name from publishers where business in (select type from titles

where titles.pub id = publishers.pub id)

ОБЪЕДИНЕНИЯ ИЛИ ПОДЗАПРОСЫ?

в многотабличных запросах SQL можно использовать как объединения, так и подзапросы, в каких случаях лучше использовать подзапросы, а в каких объединения? Одни пользователи предпочитают всегда использовать объединения, другие - подзапросы.

Однако каждый из этих подходов имеет преимущества и недостатки.

Подзапросы!

Рассмотрим, например, задачу составления перечня всех книг с ценами, равными минимальной цене книги. С помощью объединений эту задачу можно было бы выполнить в два приема.

1. Найти минимальную цену. SQL:

select min(price) from titles

Результат: ~2799

2. Получить названия всех книг, продаваемых по этой цене. SQL:

select title, price

from titles

where price =2.99

Результат:

title price

You Can Combat Computer Stress! 2.99

The Gourmet Microwave 2.99

Если сделать это с помощью подзапроса, то вам потребуется только один оператор:

SQL:

select title, price from titles where price =

(select min(price)

from titles)

Результат:

title price

You Can Combat Computer Stress! 2.99

The Gourmet Microwave 2.99

Способность вычислять значение агрегирующей функции на лету и возвращать его во внещний запрос для сравнения относится к преимуществам подзапросов; объединение не справляется с этой задачей.

Puc. 8.3. Сравнение объединения и подзапроса