Мартин Грубер - Понимание SQL
- Название:Понимание SQL
- Автор:
- Жанр:
- Издательство:неизвестно
- Год:неизвестен
- ISBN:нет данных
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Мартин Грубер - Понимание SQL краткое содержание
Данная книга является очень хорошим введением в теорию реляционных БД для пользователей-новичков, а также хорошим началом в освоении SQL, грамотном построение запросов, понимании того как эти запросы работают. Безусловно рекомендуется к прочтению для начинающих пользователей.
Понимание SQL - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
SELECT snum sname FROM Salespeople main
WHERE 1 < AND second.odate=10/03/1990;
cnum |
cname |
city |
rating |
snum |
2001 |
Hoffman |
London |
100 |
1001 |
2003 |
Liu |
San Jose |
200 |
1002 |
2008 |
Cisneros |
San Jose |
300 |
1007 |
2007 |
Pereira |
Rome |
100 |
1004 |
Таблица 11.3: Нахождение продавцов с многочислеными заказчиками
Иногда полезно выполнять запросы которые разработаны специально так чтобы находить ошибки. Это всегда возможно при дефектной информации которую можно ввести в вашу базу данных, и, если она введена, бывает трудно ее определить. Следующий запрос не должен производить никакого вывода. Он просматривает таблицу Порядков чтобы видеть совпадают ли поля snum и cnum в каждой строке таблицы Заказчиков и выводит каждую строку где этого совпадения нет. Другими словами, запрос выясняет, тот ли продавец кредитовал каждую продажу (он воспринимает поле cnum, как первичный ключ таблицы Заказчиков, который не будет иметь никаких двойных значений в этой таблице ).
SELECT *
FROM Orders main
WHERE NOT snum=
( SELECT snum
FROM Customers
WHERE cnum=main.cnum );
При использовании механизма справочной целостности (обсужденного в Главе 19 ), вы можете быть гарантированы от некоторых ошибок такого вида. Этот механизм не всегда доступен, хотя его использование желательно во всех случаях, причем поиск ошибки запроса описанный выше, может быть еще полезнее.
Вы можете также использовать соотнесенный подзапрос основанный на той же самой таблице что и основной запрос. Это даст вам возможность извлечть определенные сложные формы произведенной информации. Например, мы можем найти все порядки со значениями сумм приобретений выше среднего для их заказчиков (вывод показан в Таблице 11.4 ):
SELECT *
FROM Orders outer
WHERE amt >
( SELECT AVG amt
FROM Orders inter
WHERE inner.cnum=outer.cnum );
SELECT * FROM Orders outer WHERE amt >
(SELECT AVG (amt) FROM Orders inner
WHERE inner.cnum=outer.cnum
onum |
amt |
odate |
cnum |
snum |
3006 |
1098.19 |
10/03/1990 |
2008 |
1007 |
3010 |
1309.00 |
10/06/1990 |
2004 |
1002 |
3011 |
9891.88 |
10/06/1990 |
2006 |
1001 |
Таблица 11.4: Соотнесение таблицы с собой
Конечно, в нашей маленькой типовой таблице, где большиство заказчиков имеют только один порядок, большинство значений являются одновременно средними и следовательно не выбираются. Давайте введем команду другим способом (вывод показывается в Таблице 11.5):
SELECT *
FROM Orders outer
WHERE amt >=
( SELECT AVG (amt)
FROM Orders inner
WHERE inner.cnum=outer.cnum );
SELECT * FROM Orders outer WHERE amt > =
(SELECT AVG (amt) FROM Orders inner
WHERE inner.cnum=outer.cnum);
onum |
amt |
odate |
cnum |
snum |
3003 |
767.19 |
10/03/1990 |
2001 |
1001 |
3002 |
1900.10 |
10/03/1990 |
2007 |
1004 |
3005 |
5160.45 |
10/03/1990 |
2003 |
1002 |
3006 |
1098.19 |
10/03/1990 |
2008 |
1007 |
3009 |
1713.23 |
10/04/1990 |
2002 |
1003 |
3010 |
1309.95 |
10/06/1990 |
2004 |
1002 |
3011 |
9891.88 |
10/06/1990 |
2006 |
1001 |
Таблица 11.5: Выбераются порядки которые >=средней сумме приобретений для их заказчиков.
Различие, конечно, в том, что реляционный оператор основного предиката включает значения которые равняются среднему (что обычно означает что они - единственые порядки для данных заказчиков ).
СООТНЕСЕННЫЕ ПОДЗАПРОСЫ В ПРЕДЛОЖЕНИИ HAVING
Также как предложение HAVING может брать подзапросы, он может брать и соотнесенные подзапросы. Когда вы используете соотнесенный подзапрос в предложении HAVING, вы должны ограничивать внешние ссылки к позициям которые могли бы непосредственно использоваться в самом предложении HAVING. Вы можете вспомнить из Главы 6 что предложение HAVING может использовать только агрегатные функции которые указаны в их предложении SELECT или поля используемые в их предложении GROUP BY. Они являются только внешними ссылками, которые вы можете делать. Все это потому, что предикат предложения HAVING оценивается для каждой группы из внешнего запроса, а не для каждой строки. Следовательно, подзапрос будет выполняться один раз для каждой группы выведеной из внешнего запроса, а не для каждой строки.
Предположим что вы хотите суммировать значения сумм приобретений покупок из таблицы Порядков, сгруппировав их по датам, удалив все даты где бы SUM не был по крайней мере на 2000.00 выше максимальной (MAX ) суммы:
SELECT odate, SUM (amt)
FROM Orders a
GROUP BY odate
HAVING SUM (amt) >
( SELECT 2000.00 + MAX (amt)
FROM Orders b
WHERE a.odate=b.odate );
Подзапрос вычисляет значение MAX для всех строк с той же самой датой что и у текущей агрегатной группы основного запроса. Это должно быть выполнено, как и ранее, с испошльзованием предложения WHERE. Сам подзапрос не должен использовать предложения GROUP BY или HAVING.
Как вы и могли предположить, соотнесенные подзапросы по природе близки к обьединениям - они оба включают проверку каждой строки одной таблицы с каждой строкой другой (или псевдонимом из той же ) таблицы.
Вы найдете что большинство операций которые могут выполняться с одним из них будут также работать и с другим.
Однако имеется различие в прикладной программе между ними, такое как вышеупомянутая потребность в использовании DISTINCT с обьединением и его необязательность с подзапросом. Имеются также некоторые вещи которые каждый может делать так, как этого не может другой. Подзапросы, например, могут использовать агрегатную функцию в предикате, делая возможным выполнение операций типа нашего предыдущего примера в котором мы извлекли порядки усредненные для их заказчиков. Обьединения, с другой стороны, могут выводить строки из обеих сравниваемых таблиц, в то время как вывод подзапросов используется только в предикатах внешних запросов. Как правило, форма запроса которая кажется наиболее интуитивной будет вероятно лучшей в использовании, но при этом хорошо бы знать обе техники для тех ситуаций когда та или иная могут не работать.
Вы можете поздравлять себя с овладением большого куска из рассмотреных понятий в SQL - соотнесенного подзапроса. Вы видели как соотнесенный подзапрос связан с обьединение, а также, как как его можно использовать с агрегатными функциями и в предложении HAVING. В общем, вы теперь узнали все типы подзапросов полностью.
Читать дальшеИнтервал:
Закладка: