Изучаем.SQL

> FROM employee

> WHERE lname LIKE '_a%e%';

+ + | lname | + +

+ +

4 rows in set (0.00 sec)

Выражение поиска в предыдущем примере определяет строки, содер жащие «а» во второй позиции, за которым следует «е» в любом другом месте строки (включая последний символ). В табл. 4.5 показано еще несколько выражений поиска и их интерпретации.

Таблица 4.5. Примеры выражений поиска

Последний пример из табл. 4.5 можно использовать для поиска клиен тов, федеральный ID которых соответствует формату, используемому для номеров социальной страховки:

mysql> SELECT cust_id, fed_id> FROM customer

> WHERE fed_id LIKE '___ __ ____';

+ + + | cust_id | fed_id | + + +

+ + + 9 rows in set (0.02 sec)

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

mysql> SELECT emp_id, fname, lname> FROM employee

Этот запрос находит всех сотрудников, фамилия которых начинается с «F» или «G».

Регулярные выражения

Если символы маски не обеспечивают достаточной гибкости, для по строения выражений поиска можно использовать регулярные выра жения. По существу, регулярные выражения – это мощнейшие выра жения поиска. Регулярные выражения хорошо знакомы разработчи кам на таких языках программирования, как Perl. Если вам не дово дилось использовать их, обратитесь к книге Джеффри Фридла (Jeffrey Friedl) «Mastering Regular Expressions» (O’Reilly). Это слишком объ емная тема, чтобы пытаться охватить ее в данной книге.

Вот как выглядел бы предыдущий запрос (найти всех сотрудников с фа милиями, начинающимися с «F» или «G») с использованием реализа ции регулярных выражений MySQL:

mysql> SELECT emp_id, fname, lname> FROM employee

> WHERE lname REGEXP '^[FG]';

+ + + + | emp_id | fname | lname | + + + +

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

Оператор regexp принимает регулярное выражение (в данном примере '^[FG]') и применяет его к выражению, находящемуся в левой части условия (столбец lname). Теперь, с регулярным выражением, запрос со держит всего одно условие, а не два, как это было при использовании символов маски.

Oracle Database 10g и SQL Server 2000 тоже поддерживают регулярные выражения. При работе с Oracle Database 10g используется функция regexp_like, а не оператор regexp, показанный в предыдущем примере. А SQL Server допускает использование регулярных выражений с опе ратором like.

NULL: это слово из четырех букв…

Я, сколько мог, оттягивал этот момент, но он настал: пора обратиться к теме, которую обычно встречают с опаской, неуверенностью и трепе том, – значение null. Null – это отсутствие значения. Например, пока сотрудник не уволен, в его столбце end_date таблицы employee должно быть записано null. В данной ситуации нет значения, которое могло бы быть помещено в столбец end_date и имело бы смысл. Однако null – коварный тип, поскольку имеет несколько оттенков:

Неприменимый

Например, столбец с ID сотрудника для транзакции, которая вы полняется с банкоматом.

Значение еще не известно

Например, если в момент создания строки клиента федеральный ID неизвестен.

Значение не определено

Например, если создается счет для продукта, который еще не был добавлен в БД.

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

При работе с null необходимо помнить:

•Выражение может быть нулевым (null), но оно никогда не может быть равным нулю.

•Два null никогда не равны друг другу.

Проверить выражение на значение null можно с помощью оператора is null, как показано в следующем примере:

mysql> SELECT emp_id, fname, lname, superior_emp_id > FROM employee

> WHERE superior_emp_id IS NULL;

+ + + + + | emp_id | fname | lname | superior_emp_id | + + + + + | 1 | Michael | Smith | NULL | + + + + + 1 row in set (0.00 sec)

Этот запрос возвращает всех сотрудников, у которых нет начальника (superior). Вот тот же запрос, но вместо is null используется = null:

mysql> SELECT emp_id, fname, lname, superior_emp_id> FROM employee

> WHERE superior_emp_id = NULL;

Empty set (0.01 sec)

Как видите, запрос подвергается синтаксическому анализу и выполня ется, но не возвращает ни одной строки. Это общая ошибка неопытных SQL программистов. Сервер БД не предупредит о ней, поэтому при соз дании условий проверки на null следует соблюдать осторожность.

Проверить наличие значения в столбце можно с помощью оператора is not null:

mysql> SELECT emp_id, fname, lname, superior_emp_id> FROM employee

> WHERE superior_emp_id IS NOT NULL;

+ + + + + | emp_id | fname | lname | superior_emp_id | + + + + +

+ + + + + 17 rows in set (0.01 sec)

Эта версия запроса возвращает остальных 17 сотрудников, у которых, в отличие от Майкла Смита (Michael Smith), есть начальник.

Прежде чем на время отложить рассмотрение null, было бы полезным отметить еще одну потенциальную ловушку. Предположим, требуется идентифицировать всех сотрудников, не подчиняющихся Хелен Фле минг (Helen Fleming), ID которой равен 6. Наверняка первым порывом будет сделать следующее:

mysql> SELECT emp_id, fname, lname, superior_emp_id> FROM employee

> WHERE superior_emp_id != 6;

+ + + + + | emp_id | fname | lname | superior_emp_id | + + + + +

+ + + + + 14 rows in set (0.01 sec)

Действительно, эти 14 сотрудников не работают под руководством Хе лен Флеминг, но если внимательно посмотреть на данные, можно заме тить, что здесь пропущен один сотрудник, также не являющийся под чиненным Хелен. Это Майкл Смит, и в его столбце superior_emp_id стоит null (потому что он «большая шишка»). Поэтому, чтобы правильно от ветить на вопрос, необходимо учитывать вероятность того, что для не которых строк столбец superior_emp_id может иметь значение null.

mysql> SELECT emp_id, fname, lname, superior_emp_id> FROM employee

> WHERE superior_emp_id != 6 OR superior_emp_id IS NULL;

+ + + + + | emp_id | fname | lname | superior_emp_id | + + + + +

+ + + + + 15 rows in set (0.01 sec)

Запрос к нескольким таблицам

Поскольку реляционные БД предполагают расположение независи мых сущностей в разных таблицах, необходим механизм сведения не скольких таблиц воедино в одном запросе. Этот механизм известен как соединение (join), и данная глава посвящена самому простому и наибо лее распространенному соединению – внутреннему соединению (inner join). Все разнообразные типы соединений представлены в главе 10.

Что такое соединение?

Запросы к одной таблице, конечно, не редкость, но большинство за просов обращены к двум, трем или даже более таблицам. Для иллюст рации давайте рассмотрим описания таблиц employee и department и затем определим запрос, извлекающий данные из обеих:

mysql> DESC employee; + + + + + + | Field | Type | Null | Key | Default | + + + + + +

+ + + + + + 9 rows in set (0.11 sec)

mysql> DESC department; + + + + + +

| Field | Type | Null | Key | Default | + + + + + +

+ + + + + + 2 rows in set (0.03 sec)

Скажем, требуется выбрать имя и фамилию каждого сотрудника, а так же название отдела, в котором он работает. Поэтому запрос должен бу дет извлекать столбцы employee.fname, employee.lname и department.name. Но как можно получить данные двух таблиц одним запросом? Ответ кроется в столбце employee.dept_id, в котором хранится ID отдела каж дого сотрудника (более формально, столбец employee.dept_id является внешним ключом, ссылающимся на таблицу department). Запрос, кото рый вскоре будет представлен, указывает серверу использовать стол бец employee.dept_id как мост между таблицами employee и department, обеспечивая таким образом возможность включения столбцов обеих таблиц в результирующий набор запроса. Такой тип операции называ ется соединением.

Декартово произведение

Начнем с самого простого: поместим таблицы employee и department

вблок from запроса и посмотрим, что произойдет. Вот запрос, выбираю щий имена и фамилии сотрудников, а также название отдела. Здесь

вблоке from указаны обе таблицы, разделенные ключевым словом join:

mysql> SELECT e.fname, e.lname, d.name

> FROM employee e JOIN department d;

+ + + + | fname | lname | name | + + + +

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

Хм… у нас только 18 сотрудников и 3 разных отдела. Но как же полу чилось, что в результирующем наборе оказалось 54 строки? Пригля девшись, можно заметить, что каждый из 18 сотрудников встречается трижды. При этом все его данные идентичны, кроме названия отдела. Поскольку запрос не определил, как должны быть соединены эти две таблицы, сервер БД сгенерировал Декартово произведение, т. е. все воз можные перестановки двух таблиц (18 сотрудников умножить на 3 от дела получается 54 перестановки). Такой тип соединения называют пе рекрестным соединением (cross join). Его редко используют (намерен но, по крайней мере). Перекрестные соединения – один из типов соеди нений, которые будут изучаться в главе 10.

Внутренние соединения

Чтобы изменить предыдущий запрос и получить результирующий на бор, включающий только 18 строк (по одной для каждого сотрудника), понадобится описать взаимосвязь двух таблиц. Я уже показал, что связью между двумя таблицами служит столбец employee.dept_id, оста лось только добавить эту информацию в подблок on блока from:

mysql> SELECT e.fname, e.lname, d.name

> FROM employee e JOIN department d> ON e.dept_id = d.dept_id;

+ + + + | fname | lname | name | + + + +

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

Теперь благодаря добавлению подблока on, предписывающего серверу соединять таблицы employee и department, прослеживая связь от одной таблицы к другой по столбцу dept_id, имеем вместо 54 строк ожидае мые 18. Например, строка Сьюзен Хоторн (Susan Hawthorne) в табли це employee в столбце dept_id содержит 1 (в примере не показано). Сер вер использует это значение для поиска строки в таблице department, столбец dept_id которой содержит 1, и извлекает значение 'Operations' из столбца name этой строки.

Если определенное значение столбца dept_id присутствует в одной таб лице, но его нет в другой, соединение строк не происходит, и они не включаются в результирующий набор. Такой тип соединения называ ют внутренним соединением (inner join); это наиболее широко исполь зуемый тип соединения. Поясню: если в таблице department есть четвер тая строка для отдела маркетинга, но ни один сотрудник не приписан к нему, отдел маркетинга не попадет в результирующий набор. Анало