Изложение сведений по рассматриваемой теме в этом раздела является довольно кратким, поэтому советуем вам не торопиться и в случае необходимости еще раз возвращаться к прочитанному, особенно если вы впервые стеикиваетесь с этим материалом. Эта книга требует больше знаний и опыта от своих читателей, чем предыдущая книга автора по этой теме. Программирование баз Microsoft SQL Server 2005. Базовый курс, поскольку изложение материала в ней является чрезвычайно кратким. Еще раз рекомендуем не спешить и тщательно прорабатывать примеры.

DELETE FROM Actors FROM Actors a LEFT JOIN Film f

ON a.FilmlD = f.FilmlD WHERE f.FilmlD IS NULL;

Перейдя сразу же к рассмотрению второй конструкции FROM, можно обнаружить, что в ней используется левое соединение. Из этого следует, что будут возвращены данные обо всех актерах. Данные о кинофильмах из таблицы Film будут возвращены только в том случае, если имеется согласующийся идентификатор фильма FilmlD, если же согласование отсутствует, то в тех столбцах, которые содержат данные о кинофильмах, будут присутствовать NULL-значения. В рассматриваемом в данном примере операторе DELETE мы исходим из предложенной формулировки условия удаления и проверяем соблюдение этого условия; при обнаружении идентификатора FilmlD, вместо которого приведено NULL-значение, делается вывод, что согласование в этом конкретном случае отсутствует (поэтому должны быть удалены данные об актере).

Описание альтернативного синтаксиса соединений

в настоящем разделе рассматривается синтаксис, не соответствующий современному стандарту, но все еще рассматриваемый многими как нормальный способ составления кода операторов соединения. До появления версии SQL Server 6.5 приведенный в этом разделе альтернативный синтаксис был единственно возможным синтаксисом операторов соединения СУБД SQL Server, а тот способ оформления операторов соединения, который применяется в настоящее время и который принято называть стандартным , даже еще не был предусмотрен.

До сих пор во всех операторах SQL, рассматриваемых в данной книге, использовался синтаксис, который определен стандартом ANSL Автор настоятельно рекомендует опираться именно на стандарт ANSI, поскольку он обеспечивает гораздо лучшую переносимость между системами, а также позволяет создавать операторы, намного более удобные для чтения. Несмотря на то, что устаревший синтаксис в наше время все еще довольно широко поддерживается, на всех основных платформах предусмотрена также поддержка синтаксиса ANSL

Основная причина, по которой в данной гяаве рассматривается устаревший синтаксис, состоит в том, что любому разработчику рано или поздно придется столкнуться с ним в унаследованном коде, и в этюм нет ни малейшего сомнения. Автор не может допустить, чтобы читатели настоящей книги когда-либо недоуменно рассматривали подобный код, говоря про себя: Что бы это все значило? Несмотря на сказанное, еще раз повторим настоятельную рекомендацию, что при любой возможности следует

использовать синтаксис ANSI. Еще раз отметим, что операторы, оформленные с использованием современного синтаксиса, становятся гораздо более удобными для чтения, а представители компании Microsoft дали понять, что поддержка устаревшего синтаксиса не может продолжаться до бесконечности. Безусловно, eaiu учесть, насколько велик объем все еще эксплуатируемого унаследованного кода, трудно поверить, что вскоре настанет такое время, когда компания Microsoft запретит использование устаревшего синтаксиса, но никто не может гарантировать обратное.

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

Напомним, что выше в данной главе приведено сравнение конструкции JOIN с конструкцией WHERE. Это сравнение применялось еш;е с одной целью. Дело в том, что в устаревшем синтаксисе все условия вьшолнения соединений выражаются в конструкции WHERE.

Устаревший синтаксис поддерживает все те соединения, которые были описаны в данной главе на основе синтаксиса ANSI, за исключением операторов FULL JOIN. Поэтому даже тем разработчикам, которые упорно првдерживаются устаревшего синтаксиса, для вьшолнения полного соединения приходится прибегать к использованию синтаксиса ANSI.

Альтернативный вариант конструкции inner join

Вернемся к изложенному выше и еш;е раз рассмотрим пример применения конструкции INNER JOIN, приведенный в этой главе:

SELECT *

FROM HumanResources.Employee e INNER JOIN HumanResources.Employee m ON e.ManagerlD = m.EmployeelD;

Ho вместо использования конструкции JOIN, предусмотренной стандартом ANSI, переформулируем этот запрос на основе синтаксиса соединения, предусматривающего применение конструкции WHERE. Такая задача действительно является весьма несложной - достаточно исключить слова INNER JOIN и ввести запятую, а затем заменить операцию ON конструкцией WHERE:

SELECT *

FROM HumanResources.Employee e, HumanResources.Employee m WHERE e.ManagerlD = m.EmployeelD;

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

Рассматриваемый в этом разделе синтаксис в настоящее время поддерживается практически всеми основными системами, в которых предусмотрено использование языка SQL (Oracle, DB2, MySQL и т.д.).

Альтернативный вариант конструкции outer join

с появлением версии SQL Server 2005 возникла такая ситуация, что воспользоваться альтернативным синтаксисом OUTER JOIN можно только при соблюдении определенных условий. Фактически по умолчанию теперь этот синтаксис запрещен, и для его использования необходимо установить уровень совместимости базы данных равным 80 или меньше (в версии SQL Server 2000 он равен 80). К счастью, объем оставшегося кода, в котором по-прежнему используется этот синтаксис, весьма невелик.

Вообще говоря, настоятельно рекомендуется отказаться от этого синтаксиса как полностью устаревшего, поэтому автор не собирается посвящать ему много внимания, но устаревшие конструкции внешнего соединения действуют во много по такому же принципу, как и конструкции внутреннего соединения, если не считать того, что в применявшемся ранее синтаксисе не предусмотрены ключевые слова LEFT или RIGHT (а также, впрочем, OUTER или JOIN), поэтому требуются специальные операции, предусмотренные исключительно для выполнения этой задачи. Указанные знаки операций приведены в табл. 3.8.

Таблица 3.8. Знаки операций и ключевые слова в операторах внешнего соединения

Рассмотрим в качестве примера первый оператор с конструкцией OUTER JOIN, который бьы описан в данной главе. В этом операторе, приведенном ниже, использовалась база данных pubs.

SELECT е.EmployeelD, m.EmployeelD AS ManagerlD FROM HumanResources.Employee e LEFT OUTER JOIN HumanResources.Employee m ON e.ManagerlD = m.EmployeeID;

В этом случае также достаточно исключить слова LEFT OUTER JOIN и заменить операцию ON конструкцией WHERE:

SELECT е.EmployeelD, m.EmployeelD AS ManagerlD

FROM HumanResources.Employее e, HumanResources.Employee m

WHERE e.ManagerID *= m.EmployeelD;

Альтернативный синтаксис для внешних соединений по умолчанию не поддерживается. Для использования этого функционального средства необходимо установить уровень совместимости, меньший или равный 80.

Альтернативный вариант конструкции cross join

Приведение операторов с конструкцией CROSS JOIN к альтернативном) синтаксису является намного более простой задачей по сравнению со всеми другими конструкциями соединений. Чтобы создать с помощью альтернативного синтаксиса оператор, равнозначный оператору с конструкцией CROSS JOIN, достаточно просто оставить его