Изучаем.SQL

+ + + + +

+ + + + + 18 rows in set (0.00 sec)

Результирующий набор теперь включает Майкла Смита (Michael Smith), который является президентом банка, следовательно, начальника у не го нет. Для формирования списка всех сотрудников и их начальников, если таковые имеются, запрос использует левостороннее внешнее со единение. Если сделать внешнее соединение правосторонним, будут получены следующие результаты:

+ + + + + 28 rows in set (0.00 sec)

По этому запросу выбираются все руководители (по прежнему третий и четвертый столбцы) вместе со всеми их подчиненными. Поэтому Майкл Смит появляется дважды – как начальник Сьюзен Баркер (Su san Barker) и Роберта Тайлера (Robert Tyler). Сьюзен Баркер появляет ся один раз, она никем не руководит (значения null в первом и втором столбцах). Все 18 сотрудников появляются в третьем и четвертом столб цах, по крайней мере, один раз. Некоторые появляются несколько раз, если у них в подчинении несколько сотрудников. Таким образом, в ре зультирующем наборе 28 строк. Этот результат очень отличается от результата предыдущего запроса, а обеспечен он изменением всего од ного ключевого слова (left на right). Следовательно, при использова нии внешнего соединения необходимо тщательно продумывать, каким оно должно быть – левосторонним или правосторонним.

Перекрестные соединения

В главе 5 была представлена концепция декартова произведения, ко торое, в сущности, является результатом соединения нескольких таб лиц без указания каких либо условий соединения. Декартово произве дение довольно часто используется в результате случайности (т. е. ко гда разработчики просто забывают добавить в блок from условие соеди нения), но на самом деле не так уж широко распространено. Однако если действительно требуется получить декартово произведение двух таблиц, должно быть задано перекрестное соединение:

mysql> SELECT pt.name, p.product_cd, p.name

> FROM product p CROSS JOIN product_type pt;

+ + + + | name | product_cd | name | + + + +

+ + + + 24 rows in set (0.00 sec)

Этот запрос формирует декартово произведение таблиц product и prod uct_type. В результате получаем 24 строки (8 строк product умножают ся на 3 строки product_type). Но теперь, когда известно, что такое пере крестное соединение и как оно задается, надо определиться с тем, за чем оно используется. Большинство книг по SQL описывают, что такое перекрестное соединение, и затем говорят, что используется оно ред ко. Но мне бы хотелось поделиться с читателем ситуациями, в кото рых я нахожу перекрестное соединение довольно полезным.

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

+ + + + 3 rows in set (0.00 sec)

Хотя эта таблица является именно тем, что требовалось для разделения клиентов на три группы на основании их совокупного остатка на счете, эта стратегия слияния однострочных таблиц с помощью оператора union all не очень подходит, если требуется соорудить большую таблицу.

Например, требуется создать запрос, формирующий строку для каж дого дня 2004 года, но в БД нет таблицы, содержащей строки для всех дней. Используя стратегию из примера главы 9, можно было бы сде лать что то вроде этого:

SELECT '2004 01 01' dt UNION ALL

SELECT '2004 01 02' dt UNION ALL

SELECT '2004 01 03' dt UNION ALL

...

...

...

SELECT '2004 12 29' dt UNION ALL

SELECT '2004 12 30' dt UNION ALL

SELECT '2004 12 31' dt

Создавать запрос, соединяющий результаты 366 запросов, немного уто мительно, поэтому, наверное, нужна другая стратегия. Что если сгене рировать таблицу с 366 строками (2004 год был високосным) и одним столбцом, содержащим число от 0 до 366, и затем добавлять это число дней к 1 января 2004? Вот одна из возможных методик формирования подобной таблицы:

+ + | ones.num + tens.num + hundreds.num | + +

+ + 400 rows in set (0.00 sec)

Если найти декартово произведение трех наборов – {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}, {0, 10, 20, 30, 40, 50, 60, 70, 80, 90} и {0, 100, 200, 300} – и сло жить значения во всех трех столбцах, получится результат, состоя щий из 400 строк, содержащих все числа от 0 до 399. Хотя это больше 366 строк, необходимых для формирования набора дней 2004 года, из бавиться от лишних строк достаточно просто. Вскоре я покажу, как это сделать.

Следующий шаг – преобразовать числа в набор дат. Для этого восполь зуемся функцией date_add() и добавим каждое число в результирую щий набор к 1 января 2004 года. Затем введем условие фильтрации, чтобы отбросить все даты 2005 года.

| 2004 01 02 | | 2004 01 03 | | 2004 01 04 | | 2004 01 05 | | 2004 01 06 | | 2004 01 07 | | 2004 01 08 | | 2004 01 09 | | 2004 01 10 |

...

...

...

| 2004 02 20 | | 2004 02 21 | | 2004 02 22 | | 2004 02 23 |

| 2004 02 24 | | 2004 02 25 | | 2004 02 26 | | 2004 02 27 | | 2004 02 28 | | 2004 02 29 | | 2004 03 01 |

...

...

...

| 2004 12 20 | | 2004 12 21 | | 2004 12 22 | | 2004 12 23 | | 2004 12 24 | | 2004 12 25 | | 2004 12 26 | | 2004 12 27 | | 2004 12 28 | | 2004 12 29 | | 2004 12 30 | | 2004 12 31 | + +

366 rows in set (0.01 sec)

В этом подходе замечательно то, что результирующий набор автомати чески включает 29 февраля без всяких дополнительных вмеша тельств, поскольку сервер БД вычисляет его, когда добавляет 59 дней к 1 января 2004 года.

Теперь, когда у нас есть механизм получения всех дней 2004 года, что мы должны с ними сделать? Ну, может потребоваться сгенерировать запрос, по которому будут выводиться все дни 2004 года с номерами счетов, открытых в каждый из дней, с числом осуществленных опера ций и т. д. Вот пример, дающий ответ на первый вопрос:

+ + + 366 rows in set (0.03 sec)

Это один из самых интересных запросов, встречавшихся до сих пор в данной книге. Его ценность в том, что он включает перекрестные со единения, внешние соединения, функцию работы с датами, группи ровку, операции с множествами (union all) и агрегатную функцию (count()). Это не самое элегантное решение заданной проблемы, но оно послужит примером того, как с небольшой долей творчества и твер дым знанием языка программирования даже такой редко используе мый механизм, как перекрестные соединения, можно сделать могуще ственным инструментом в наборе инструментов SQL.

Естественные соединения

Если вы ленивы (а кто не ленив?), можно выбрать тип соединения, при котором сервер БД сам определяет необходимые условия соединения указанных вами таблиц. Известный как естественное соединение (na tural join), этот тип соединения делает предположение о необходимых условиях соединения, полагаясь на идентичные имена столбцов в таб лицах. Например, таблица account включает столбец cust_id, являю щийся внешним ключом к таблице customer, первичный ключ которой также имеет имя cust_id. Таким образом, можно написать запрос, ис пользующий для соединения этих двух таблиц natural join:

mysql> SELECT a.account_id, a.cust_id, c.cust_type_cd, c.fed_id

> FROM account a NATURAL JOIN customer c;

+ + + + + | account_id | cust_id | cust_type_cd | fed_id | + + + + +

+ + + + + 24 rows in set (0.02 sec)

Поскольку задано естественное соединение, сервер проверил описания таблиц и добавил для этих двух таблиц условие соединения a.cust_id = c.cust_id.

Все это хорошо и замечательно, но что будет, если имена столбцов в таблицах не совпадают? Например, в таблице account также есть внешний ключ к таблице branch, но этот столбец в таблице account на зван open_branch_id, а не branch_id. Посмотрим, что произойдет, если попытаться провести natural join между таблицами account и branch:

mysql> SELECT a.account_id, a.cust_id, a.open_branch_id,

> FROM account a NATURAL JOIN branch b;

+ + + + + | account_id | cust_id | open_branch_id | name | + + + + +