Полученные результаты будут выгладеть примерно так:

Асhong Abel

Abercrombie Не

Zheng Ни

Обратите внимание на то, что в целях сокращения строки, находящиеся в середине, удалены, поскольку данный запрос приводит к получению 19972 строк. В данном случае было решено получить список фамилий всех заказчиков, поэтому и была применена конструкция, предназначенная для выборки всех этих данных.

Этот запрос является довольно несложным, но по мере того как запросы становятся все более длинными, все чаще возникает необходимость предусматривать псевдонимы для тех или иных таблиц; это можно сделать, добавив псевдоним, предназначенный для дальнейшего использования в операторе запроса, после имени таблицы. SELECT LastName FROM Person.Contact c;

В рассматриваемом примере псевдоним задан, но фактически с его помощью не осуществляются какие-либо действия. Но в случае применения более сложного оператора этот псевдоним может действительно использоваться для ссылки на ту же таблицу в другой конструкции запроса: SELECT с.LastName FROM Person.Contact с;

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

Многие разработчики, использующие язык SQL, стремятся создавать как можно более краткие запросы и всегда предусматривают выборку всех столбцов, используя символ * в качестве критерия выборки. Это - еще одна дурная привычка, которую нельзя усваивать. Безусловно, если ввести символ * вместо требуемых имен столбцов, то ш понадобится несколько раз нажимать клавиши, но вместе с тем объем данных, поступающих из базы данных, становится больше, чем действительно требуется. Кроме того, на СУБД SQL Server возлагается дополнительная нагрузка, связанная с -необходимостью уточнять количество столбцов, подразумеваемых под символом *, а также определять, какими именно являются эти столбцы. Часто после перехода от конкретного указания столбцов к использованию символа * разработчик с удивлением обнаруживает, насколько снизилась производительность приложения и увеличился объем данных, передаваемых по сети. Иными словами, настоятельно рекомендуется предусматривать выборку только тех данных, которые действительно требуются.

Конструкция JOIN

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

Современные базы данных, как правило, являются нормализованными; в процессе нормализации данные, которые можно было бы хранить и в более крупных таблицах, тем не менее распределяются по многочисленным меньшим таблицам в целях устранения повторяющрххся данных, сокращения объема занимаемого дискового пространства, повышения производительности и обеспечения целостности данных. Решение задачи нормализации требует больших усилий и является крайне важным для реляционных баз данных, но после полного достижения целей нормализации обнаруживается также, что необходимые данные приходится извлекать из одной, другой, третьей таблицы и т.д. Соединения полностью предназначены для обеспечения выборки данных из нескольких таблиц и включения этих данных в один результирующий набор. Конструкции JOIN применяются в операторах выборки данньгх в нескольких разных формах, и от выбора конкретной формы зависит то, как осуществляется взаимодействие таблиц, входящих в соединение. Кроме того, для создания конструкций JOIN применяются два варианта синтаксиса, старый и новый; настоящая глава посвящена в основном описанию нового варианта синтаксиса, а старый вариант рассматривается в самОхМ конце главы (поскольку, прежде чем ознакомиться с ним, необ-ХОДР1МО рассмотреть еще несколько понятрш).

Основные сведения о конструкции join

Во время работы с данными, хранящимися в нормализованной базе данньгх, часто приходится сталкиваться с ситуациями, в которых всю необходимую информацию невозможно получить только из одной таблицы. В других случа51х вся информация, которая должна быть получена, находится в одной таблице, но выборка этих данньгх должна осуществляться в соответствии с условиями, подлежащими проверке по другой таблице. Именно в этих ситуаци51х невозможно обойтись без применения констр}тсции JOIN.

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

Например, предположим, что строки с данными о кинофильмах берутся из таблицы Films (табл. 3.1).

Таблица 3.1. Одна строка из таблицы Films

Теперь перейдем к рассмотрению строк из таблицы с данными об актерах, называемой Actors (табл. 3.2).

Таблица 3.2. Две строки из таблицы Actors

FilmlD FirstName LastName

1 Rex Harrison

1 Audrey Hepburn

Конструкция JOIN позволяет создать одну строку из двух строк, находящихся в полностью отдельных таблицах (табл. 3.3).

Таблица 3.3. Результаты соединения данных из таблиц Films и Actors

Фактически в данном случае из общего количества записей, равного трем, были созданы две записи (одна из исходных записей находится в одной таблице, а две - в другой). Одна и та же запись из таблицы Films использовалась несколько раз, по одному разу применительно к данным о каждом актере, к которому она относится (поскольку соединение осуществляется по данным поля FilmlD).

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

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

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

Дополним рассматриваемые таблицы и проверим, какие результаты могут быть получены с помощью конструкции INNER JOIN. Допустим, что теперь таблица Films имеет такой вид, как показано в табл. 3.4.

Таблица 3.4. Еще один вариант таблицы Films