Главная » Microsoft SQL Server, Базы данных » Основы создания запроса

0

Каждый может подойти к задаче создания запроса разными путями. Я, например, при создании кода SQL рассматриваю запрос с помощью логического метода, хотя многие подходят к нему с точки зрения конструктора запросов утилиты Management Studio. Еще один подход предлагает сам синтаксис инструкции SELECT. Для того чтобы проиллюстрировать декларативную природу запроса, следует сказать, что как бы вы ни поступили, при физическом выполнении запроса будет все равно использован другой, оптимизированный порядок.

Синтаксическая организация инструкции запроса

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

Ниже приведен упрощенный синтаксис инструкции SELECT.

SELECT *, столбцы или выражения

[FROM таблица]

[JOIN таблица ON условие]

[WHERE условия]

[GROUP BY столбцы]

[HAVING условия]

[ORDER BY столбцы];

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

SELECT 1;

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

Предложение WHERE фильтрует строки набора данных, собранного предложением FROM, на основе некоторых условий.

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

Наконец, предложение ORDER BY определяет порядок сортировки результирующего набора данных.

Графическое представление инструкции запроса

Утилита SQL Server Management Studio содержит два основных инструмента формирования и отправки запросов: конструктор запросов (Query Designer) и редактор запросов (Query Editor). Конструктор запросов предлагает графический метод создания запроса. В то же время редактор запросов является идеальным средством разового извлечения данных, так как не содержит графики, указывающей пользователю, как именно он должен создавать запрос. В редакторе пользователь работает с кодом SQL настолько близко, насколько это возможно.

С точки зрения SQL Server не имеет значения, откуда именно исходит запрос. Каждая инструкция оценивается и обрабатывается как одна инструкция SQL.

Когда данные отбираются с помощью конструктора запросов, инструкции SQL можно вручную вводить и редактировать на третьей панели (рис. 7.1). Нижняя панель отображает результаты выполнения запроса в табличном или текстовом режиме; также на ней отображаются различные сообщения. В окне Object Browser отображается дерево всех объектов SQL Server, равно как и шаблоны для создания новых объектов с помощью кода.

Если в окне запроса SQL выделен какой-либо текст, то после нажатия клавиши Совет   <F5> или щелчка на кнопке Execute Query будет выполнена только эта часть

запроса. Это отличный способ тестирования кода SQL по частям.

Базой данных по умолчанию является master, хотя этот факт сильно зависит С°вет         от настроек системы безопасности. Перед выполнением запроса убедитесь,

что в комбинированном списке на панели инструментов выбрана пользова- > тельская база данных; также для этого можно воспользоваться командой use база_данных.

Логическая структура запроса

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

1.              FROM. Выполнение запроса начинается с подготовки изначального набора данных; порядок сбора источников данных указан в предложении FROM.

2.              WHERE. Процесс фильтрации, определяемый в предложении WHERE, отбирает только те строки, для которых квалификационная характеристика содержит фразу ” %First Aid%”.

3.              Вычисление столбцов. Как только строки доступны и отфильтрованы, из них отбираются и вычисляются столбцы, указанные в списке инструкции SELECT.

Дополнительная Структура выражений SQL детально рассматривается в главе 8.

информация

4.              Консолидация. При необходимости SQL может осуществлять консолидацию на множестве данных, таких как поиск среднего значения, группировка данных по значениям в заданном столбце, или преобразование результата в сводную (или перекрестную) таблицу.

Итоговые функции SQL будут рассмотрены в главе 11.

Новинка ‘

2005

5.              ORDER BY. Как только строки будут собраны предложением FROM и отфильтрованы предложением WHERE, они могут быть отсортированы в соответствии с предложением ORDER BY.

6.              Предикат. После того как строки отобраны, вычисления выполнены и данные отсортированы в заданном порядке, SQL может ограничить результирующий набор только первыми несколькими строками или вернуть заданный набор строк.

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

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

Физическая структура запроса

SQL Server принимает инструкцию SELECT и вырабатывает план выполнения запроса. Как вы уже догадались, это не что иное, как порядок выполняемых операций (рис. 7.2).

Предложение from для выбора источников данных

Первым компонентом типичной инструкции SELECT является предложение FROM. В простых инструкциях отбора предложение FROM содержит всего одну таблицу. Однако это предложение может содержать и множество связанных между собой таблиц, подзапросы в качестве временных таблиц, а также представления. Максимальное количество таблиц, доступных одной инструкции SELECT, составляет 256.

Puc. 7.2. Физический план выполнения запроса сильно отличается от синтаксической и логической структуры запроса

Предложение FROM закладывает фундамент всех последующих операций инструкции SELECT. Для того чтобы столбец таблицы содержался в результирующем наборе данных, или был доступен условиям предложения WHERE, или стал основой сортировки в предложении ORDER BY, эта таблица должна быть упомянута в предложении FROM.

Возможные источники данных

Язык SQL является чрезвычайно гибким и может принимать данные из множества различных типов источников, упомянутых в предложении FROM.

?               Таблицы SQL Server.

?               Подзапросы, выступающие в роли временных таблиц, также называемые подвыборка- ми и оперативными представлениями. О них мы подробно поговорим в главе 10.

?               Общие табличные представления (СТЕ), впервые введенные в SQL Server 2005, добавляют новые функции и форматирование в традиционные подзапросы.

?               Представления, или хранимые инструкции SELECT, доступны предложению FROM так, будто они являются обычными таблицами. Представления мы подробно рассмотрим в главе 14.

?               Определенные пользователем функции, возвращающие таблицы. Более полная информация о пользовательских функциях приведена в главе 22.

?               Распределенные источники данных, перемещенные из других баз и приложений (например, Oracle, Excel или Access) с помощью функции openquery () и других, описанных в главе 15.

?               Работа с источниками данных XML выполняется с помощью запросов Xquery. Более подробно эта тема освещена в главе 31.

Именованные диапазоны

Любой таблице в предложении FROM может быть присвоен именованный диапазон, или псевдоним. Как только у таблицы появляется псевдоним, по нему к ней можно обращаться в других предложениях инструкции SELECT. Ключевое слово AS является необязательным, и часто его обходят вниманием. В следующем примере доступ осуществляется к таблице Guide, но обращение к ней выполняется по псевдониму G:

— FROM таблица [AS] переменная_диапазона USE СНА2

SELECT G.LastName, G.FifstName FROM Guide AS G

На сайте книги (www.SQLServerBible.com) вы найдете примеры программ для всех глав этой книги, а также сценарии, создающие и заполняющие базы данных примеров.

На языке SQL команда use задает текущую базу данных. Это программная версия выбора базы данных в утилите Management Studio.

Имя таблицы

Если имя объекта базы данных, такого как таблица или столбец, конфликтует с каким- либо ключевым словом SQL, вы можете указать серверу, что это именно имя объекта, заключив его в квадратные скобки. Таблица [Order] (заказ) в базе данных OBXKites является типичным примером использования ключевого слова в имени таблицы.

USE OBXKites

SELECT OrderlD, OrderDate FROM [Order]

Несмотря на то что считается дурным тоном включать в имена объектов базы данных пробелы, некоторые разработчики настроены по-другому. В данном случае при указании имени объекта также используются квадратные скобки. Таблица Order Details в базе данных примеров Northwind иллюстрирует это правило:

USE Northwind

SELECT OrderID, ProductID, Quantity FROM [Order Details]

Четырехкомпонентные имена таблиц

Полное и правильное имя таблицы складывается из четырех составных частей:

Сервер. База_данных. Схема . Таблица

Если таблица находится в текущей базе данных, то имена сервера и базы не обязательны. Хотя это и не обязательно, но считается хорошим тоном указывать явно имя схемы. Обычно схемой является dbo — это наследие предыдущих версий SQL Server, где все объекты принадлежали владельцам, а имя dbo представляло владельца базы данных.

Использование четырехкомпонентного имени позволяет многократно использовать план выполнения запроса. Указание имени владельца— это не только хорошая программистская практика, но и способ повышения быстродействия запросов.

Теперь, когда вы ознакомились с четырехкомпонентной формой имен объектов базы данных, во всех примерах книги в именах в явном виде будет указываться владелец.

Дополнительная Чтобы ближе ознакомиться с вопросами схем, областей определения и разре- ^информация шений, обратитесь к главе 40. Многократное использование планов выполнения запросов рассматривается в главе 50.

Условия WHERE

Условия WHERE фильтруют набор данных, сформированный предложением FROM, и отбирают из него только те строки, которые войдут в результирующий набор данных. Условия могут ссылаться на данные в таблицах, выражения, встроенные скалярные функции SQL и пользовательские функции. В условиях WHERE могут также использоваться операторы сравнения и символы макроподстановки, перечисленные в табл. 7.1.

Одним из способов существенного повышения производительности баз данных с архитектурой “клиент/сервер” является разрешение ядру базы данных выполнять работу по ограничению числа возвращаемых строк, вместо того чтобы нагружать вызывающее приложение ненужными ему данными. В то же время, если структура базы данных для обнаружения нужных строк требует использования в предложении where функций, производительность существенно упадет, так как функции будут выполняться над каждой из строк. Таким образом, правильно составленное предложение where, основанное на хорошо спланированной структуре базы данных, является самым главным рычагом повышения производительности запросов в руках разработчика.

Таблица 7.1. Стандартные операторы сравнения
Описание Оператор Пример
Равно = Quantity=12
Больше > Quantity>12
Больше или равно >= Quantity>=12
Меньше < Quantity<12
Меньше или равно <= Quantity<=12
Не равно <>, ! = Quantity<>12, Quantity!=12
Не меньше ! < Quantity!<12
Не больше ! > Quantity!>12

Операторы сравнения, содержащие восклицательный знак, не совместимы со стандартом ANSI. В частности, оператор <> допустим, а оператор ! = — нет.

В дополнение к стандартным операторам сравнения, которые, без сомнения, вам знакомы, в языке SQL содержатся специальные операторы between, in, like и is. Первые три из них будут описаны в настоящем разделе. Тестирование отсутствующих значений, выполняемое оператором is, а также сама обработка пустых значений будут описаны в главе 8.

Лучшим способом найти какую-либо вещь является поиск именно ее, а не отсев всех вещей, которыми она не является. Гораздо проще найти в городе конкретную фирму, чем доказать, что ее не существует. То же справедливо и для поиска в базах данных. Доказательство того, что строка удовлетворяет условию, выполняется быстрее, чем отсев всех строк, не удовлетворяющих условию. В общем случае замена отрицательного условия where положительным условием значительно повышает производительность запроса.

Использование условия between

Условие BETWEEN проверяет значение на его принадлежность некоторому диапазону. В данном случае диапазон включает граничные значения. Например, условие between 1 and 10 будет справедливо для чисел 1 и 10. При использовании условия between первая граница диапазона должна быть меньше второй, так как в переводе на “человеческий” язык это условие звучит так: “Больше или равно первому значению и меньше или равно второму”.

Чаще всего условие between используют с датами. В следующем примере (рис. 7.3) выполняется поиск всех событий из базы данных Cape Hatteras Adventures, произошедших с июля 2001 года. В начале программы база данных СНА2 объявляется текущей, а затем к ней выполняется запрос:

USE СНА2

SELECT EventCode, DateBegin FROM dbo.Event

Результат выполнения запроса следующий:

WHERE DateBegin BETWEEN ’07/01/01′ AND ’07/31/01′;

Рис. 7.3. Условия предложения WHERE в конструкторе запросов утилиты Management Studio можно поместить как на панель таблицы, так и на панель SQL

Приведенный в качестве примера запрос возвращает точный результат только в том случае, если даты хранятся без указания времени. В то же время в большинстве приложений дата и время извлекаются с помощью встроенной функции SQL Server Get Date (), которая одновременно извлекает обе величины. При этом точность извлечения времени составляет 3 миллисекунды. Таким образом, в данном случае приведенный в качестве примера запрос теоретически должен не включать в себя строки с датой и временем более 00:00:00.000 31/07/2001. Однако в случае одновременного хранения даты и времени последним известным временем для SQL Server будет 23:59:59:998, что и продемонстрировано в следующем примере. В этом примере мы вначале создаем базу данных для тестирования, заполняем ее несколькими строками данных, а затем выполняем запрос, иллюстрирующий рассматриваемый вопрос:

CREATE TABLE dbo.DateTest(

PK INT IDENTITY,

OrderDate DATETIME )

go

INSERT dbo.DateTest(OrderDate)

VALUES(*1/1/01 00:00′)

INSERT dbo.DateTest(OrderDate)

VALUES(‘1/1/01 23:59′)

INSERT dbo.DateTest(OrderDate)

VALUES(‘1/1/01 11:59:59.995 pm’)

INSERT dbo.DateTest(OrderDate)

VALUES(‘1/2/01′ ) ;

Следующий пример демонстрирует последнее доступное время дня:

SELECT *

FROM dbo.DateTest

WHERE OrderDate BETWEEN ‘1/1/1′ AND ‘1/1/1 11:59:59.998 PM';

Результат выполнения этого запроса:

PK         OrderDate

1 01-01-2001 00:00:00.000

2                  01-01-2001 23:59:00.000

3                  01-01-2001 23:59:59.997

SQL Server автоматически корректирует запрос к ближайшим трем миллисекундам, в результате чего получается ошибочный набор данных:

SELECT *

FROM dbo.DateTest

WHERE OrderDate BETWEEN ‘1/1/1′ AND ‘l/l/l 11:59:59.999 PM';

Результат выполнения этого запроса:

PK         OrderDate

1                                                                                                       01-01-2001 00:00:00.000

2                  01-01-2001 23:59:00.000

3                  01-01-2001 23:59:59.997

4                  02-01-2001 00:00:00.000

Теперь удалим тестовую таблицу:

DROP TABLE DateTest

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

Та же проблема возникает и при использовании типа данных smalldatetime, в котором время округляется до минуты. В результате условие предложения WHERE column<=23 :59 :30 будет округлено до нуля часов следующего дня.

Следующий запрос из сценария FamilyQueries . Sql использует условие between для поиска матерей, которые родили детей менее чем через 9 месяцев после замужества.

В предложении FROM данный запрос собирает информацию о матерях, о датах заключения их брака и рождении детей из таблицы person. После этого предложение WHERE ограничивает результат теми строками, в которых поле DateOfBirth (дата рождения ребенка) попадает в конкретный временной диапазон:

SELECT Person.FirstName + 1 ‘ + Person.LastName AS Mother,

Convert(Char(12), Marriage.DateOfWedding, 107) as Wedding,

Child.FirstName + ‘ ‘ + Child.LastName as Child,

Convert(Char(12), Child.DateOfBirth, 107) as Birth FROM Person JOIN Marriage

ON Person.PersonID = Marriage.WifelD JOIN Person Child

ON Person.PersonID = Child.MotherlD WHERE Child.DateOfBirth BETWEENMarriage.DateOfWedding

AND DATEADD(mm, 9, Marriage.DateOfWedding);

Результат выполнения данного запроса:

Mother    Wedding       Child            Birth

Alysia Halloway Jan 01, 1975 James Halloway May 24, 1975

Использование условия in

Условие поиска in аналогично оператору сравнения equals, однако в данном случае ищется соответствие данным из списка. Если значение содержится в списке, то результатом выражения будет true. Например, если данные о регионе ввести в базу Cape Hatteras Adventures, то следующий код найдет все базовые лагеря в Северной Каролине (NC) и Западной Виргинии (WV):

USE СНА2

SELECT BaseCampname FROM dbo.BaseCamp WHERE Region IN(1NC’, 1WV’);

Результат выполнения запроса будет следующим:

Result:

BaseCampName

West Virginia Cape Hatteras Asheville NC

Фактически условие запроса in является эквивалентом объединения оператором or нескольких сравнений equals. Предыдущий запрос можно было бы заменить следующим:

USE СНА2

SELECT BaseCampname

FROM dbo.BaseCamp

WHERE Region = ‘NC’ORRegion = ‘WV';

Как видим, результат его выполнения не отличается от предыдущего:

BaseCampName

West Virginia Cape Hatteras Asheville NC

Оператор in можно комбинировать с оператором not для исключения соответствующих строк. Например, предложение where not in ( ‘ NC’ , ‘ SC ‘ ) вернет все строки базовых лагерей за исключением находящихся в Северной и Южной Каролине:

USE СНА2

SELECT BaseCampname FROM dbo.BaseCamp

WHERE Region NOT IN (‘NC’, ‘SC’);

Результат будет следующим:

BaseCampName

FreePortFt

LauderdaleWest

Virginia

Очень трудно доказать обратное, особенно если в списке содержится пустое значение NULL. Пустое значение как бы неизвестно, поэтому потенциально любое значение может находиться на его месте. Следующая инструкция демонстрирует, как включение в список пустого значения делает невозможным доказательство отсутствия в нем буквы ‘ А':

SELECT ‘IN’ WHERE ‘A’ NOT IN (‘В’,NULL)

Эта инструкция не вернет результат, поскольку пустое значение потенциально может быть буквой ‘ А’. Поскольку SQL не может логически доказать отсутствия этой буквы в списке, предложение WHERE возвращает значение false. Когда бы оператор not in ни использовался со списком, содержащим пустое значение, любая строка будет оценена как не удовлетворяющая условию.

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

Использование условия like

Условие like использует символы макроподстановки для поиска строк, соответствующих заданному шаблону. Однако эти символы макроподстановки отличаются от использующихся в DOS, с которыми вы, наверное, хорошо знакомы. В табл. 7.2 представлены символы макроподстановки как SQL, так и MS-DOS.

В следующем примере условие like используется для поиска всех товаров, названия которых начинаются с ‘ Air ‘:

USE OBXKites SELECT ProductName FROM dbo.Product WHERE ProductName LIKE ‘Air%’;

Результат будет следующим:

ProductName

Air Writer 36 Air Writer 48 Air Writer 66

Следующий запрос ищет названия всех товаров, начинающихся с букв диапазона от ‘ а’ до ‘ d’ включительно:

SELECT ProductName FROM Product

WHERE ProductName LIKE 1[a-d]%*;

Результат его выполнения будет следующим:

ProductName

Basic Box Kite 21 inch Dragon Flight Chinese 6″ Kite Air Writer 36 Air Writer 48 Air Writer 66 Competition 36″

Competition Pro 48″

Black Ghost Basic Kite Flight Advanced Acrobatics Adventures in the OuterBanks Cape Hatteras T-Shirt

Для поиска по шаблонам, содержащим символы макроподстановки, можно использовать два метода: либо заключить шаблон в квадратные скобки, либо поместить перед ним символ Escape. Нюанс последнего подхода состоит в том, что символ Escape должен быть определен в выражении like.

В следующих двух примерах выполняется поиск фразы “F-15″ в таблице product базы данных OBXKites. В первом запросе дефис заключается в квадратные скобки, что указывает на то, что это символ макроподстановки. Во втором запросе символ амперсанда (&) определяется как символ Escape:

SELECT ProductCode, ProductName FROM Product

WHERE ProductName LIKE ‘%F [-]15%?;

SELECT ProductCode, ProductName

FROM Product

WHERE ProductName LIKE ‘%F&-15%’ ESCAPE Оба запроса возвращают один и тот же результат:

ProductCode  ProductName

1013              Eagle F-15

Из двух методов поиска с использованием символов макроподстановки квад- Внимание! ратные скобки являются специфичным методом Т-SQL, не соответствующим стандарту ANSI SQL. В то же время метод Escape является одновременно соответствующим стандарту ANSI SQL и, следовательно, переносимым.

При использовании оператора like учтите, что порядок сортировки символов в базе данных должен различать символы верхнего и нижнего регистра и соответствовать предусмотренному вами в запросе. При желании вы можете использовать необязательное ключевое слово collate, чтобы явно определить порядок сопоставления, используемый в операторе like.

Несмотря на то что оператор like может оказаться исключительно полезным, его использование может сказаться на производительности. Индексы основываются на первых символах столбцов, а не на фразах в их середине. Если оказалось, что приложению часто нужно использовать оператор like, то лучше активизируйте полнотекстовую индексацию. Это метод индексации, который принимает в расчет взвешенные комбинации слов и в возвращаемой таблице указывает степень соответствия найденной фразы заданной фразе. Более подробно о полнотекстовой индексации вы узнаете в главе 13.

Множественные условия where

В предложении WHERE можно комбинировать множество условий с помощью логических булевых операторов and, or и not. Как и в математических операторах, в булевых логических операторах существует свой порядок приоритетов. Наивысший приоритет имеет оператор and, далее следует or и, наконец, not. Рассмотрим пример:

SELECT ProductCode, ProductName FROM dbo.Product WHERE

ProductName LIKE ‘Air%’

OR

ProductCode BETWEEN ‘1018’ AND ‘1020’

AND

ProductName LIKE ‘%G%';

Результат будет следующим:

ProductCode  ProductName

1009                      Air Writer 36

1010                      Air Writer 48

1011                      Air Writer 66

1019                      Grand Daddy

1020                      Black Ghost

Если в выражении использовать скобки, то результат запроса радикально изменится:

SELECT ProductCode, ProductName FROM dbo.Product WHERE

(ProductName LIKE ‘Air%’

AND

ProductName LIKE ‘%G%';

Теперь результат выглядит так:

ProductCode       ProductName

1019                  Grand Daddy

1020                  Black Ghost

Несмотря на то что два приведенных запроса очень похожи, в первом из них использовался естественный порядок приоритетов булевых операторов, т.е. and вычислялся перед or. При этом оператор or включил в результаты товары Air Writer.

Во втором запросе с помощью скобок была явно задана последовательность булевых операторов. Оператор or объединил все товары Air Writer с товарами, имеющими коды 1018, 1019 и 1020. После этого оператор and отобрал из этого списка только те товары, в названиях которых содержалась буква д. Только товары с кодами 1019 и 1020 прошли оба этих теста.

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

SELECT…WHERE

Это удивительно, но при использовании в инструкции SELECT предложения WHERE совершенно не обязательно использование предложения FROM или каких-либо ссылок на таблицы. Инструкция SELECT без предложения FROM выдает одну строку.

Например, результатом инструкции SELECT ‘abc1 будет строка abc

Предложение WHERE в нетабличной инструкции SELECT служит ограничением, применяемым ко всей инструкции. Если условие WHERE истинно, то инструкция SELECT будет работать, как и предполагалось.

Результатом инструкции SELECT ‘abc’ WHERE 1>0 будет та же строка abc

Если же условие WHERE ложно, то инструкция SELECT вообще не выполняется:

DECLARE @test NVARCHAR(15) ;

SET @test = ‘z';

SELECT @test = ‘abc’ WHERE 1<0;

SELECT @test;

Результатом будет символ 1 z ’. По своей функции предложение WHERE в нетабличной инструкции SELECT является сокращенным аналогом оператора IF. Следующий пример является полным аналогом предыдущего:

DECLARE @test NVARCHAR(15);

SET @test = 1z’;

IF 1<OSELECT ©test = ‘abc’ ;

SELECT ©test;

Результатом этого кода также будет символ ‘ z’.

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии