Хелен Борри - Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

Следующие простые примеры иллюстрируют некоторые предложения WHERE, использующие условия выборки для ограничения отыскиваемых строк:

SELECT COLUMN 1, C0LUMN2 FROM ATABLE

WHERE ADATE BETWEEN '2002-12-25' AND '2004-12-24'...

/**/

SELECT TL.ID, T2.TITLE, CURRENT_TIMESTAMP AS RETRIEVE_DATE

FROM TABLEA

JOIN TABLEB

ON TABLEA.ID = TABLEB.ID_B

WHERE TABLEA.ID = 99 ;

/**/

SELECT MAX(COST * QUANTITY) AS BEST_SALE

FROM SALES

WHERE SALES_DATE > '31.12.2003'...

Глава 21 посвящена выражениям и предикатам, используемым в условиях поиска.

Интерфейсы доступа к данным, реализованные в API Firebird, имеют возможность обрабатывать константы в условиях поиска как заменяемые параметры. Следовательно, приложение может создавать оператор с динамическими условиями поиска в предложении WHERE, значения которых можно устанавливать непосредственно перед выполнением запроса. Такая возможность иногда называется динамическим связыванием.

Подробности см. в одном из следующих разд. "Использование параметров".

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

Следующий простой пример иллюстрирует группирующий запрос. Агрегатная SQL - функция SUMO используется для вычисления общего количества продаж для каждого типа продукции:

SELECT PRODUCT_TYPE, SUM(NUMBER_SOLD) AS SUM_SALES

FROM TABLEA

WHERE SERIAL_NO BETWEEN 'A' AND 'K'

GROUP BY PRODUCT_TYPE;

Результат может быть похожим на следующий:

PRODUCT TYPE SUM SALES

Gadgets 174

Whatsits 25

Widgets 117

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

! ! !

ВНИМАНИЕ! Если вы конвертируете базу данных из InterBase в Firebird, то это одна из областей, где вам нужно помнить о различиях. Firebird является менее терпимым к нелогичным спецификациям группирования, чем его предшественник. Это позволяет исключить возможность выполнения запросов, возвращающих некорректные результаты.

. ! .

Обобщающие выражения обсуждаются в главе 21. Подробную информацию о предложении GROUP BY см. в главе 23.

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

Изменим предыдущий пример, добавив предложение HAVING для получения только тех PRODUCT_TYPE, которые имели количество продаж больше 100:

SELECT PRODUCT_TYPE, SUM(NUMBER_SOLD) AS SUM_SALES

FROM TABLEA

WHERE SERIAL_NO BETWEEN 'A' AND 'K'

AND PRODUCT_TYPE = 'WIDGETS'

GROUP BY PRODUCT_TYPE

HAVING SUM(NUMBER_SOLD) > 100;

Вывод будет таким:

PRODUCT TYPE SUM SALES

Widgets 117

Наборы UNION формируются объединением двух или более спецификаций запросов, которые могут использовать различные таблицы, в один выходной набор. Единственное ограничение - выходные столбцы в каждой выходной спецификации должны соответствовать по степени, типу и размеру. Это означает, что в каждом выходе должно быть то же количество столбцов в том же порядке слева направо, и каждый столбец должен быть совместим по типу данных и размеру.

По умолчанию UNION убирает дубликаты в финальном выходном наборе. Для сохранения всех дубликатов добавьте ключевое слово ALL [71] Если два набора, объединяемых UNION, принципиально не будут содержать дубликатов строк, необходимо использовать UNION ALL, чтобы сервер не занимался зря работой по удалению несуществующих дубликатов строк. - Прим. науч. ред. .

Наборы UNION подробно обсуждаются в главе 23.

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

Планы запросов и синтаксис выражений плана обсуждаются в разд. "Тема оптимизации" главы 22.

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

SELECT EMP_NO, LAST_NAME, FIRST_NAME FROM EMPLOYEE

ORDER BY LAST_NAME, FIRST_NAME;

В отличие от столбцов GROUP BY столбцы в ORDER BY не обязательно должны присутствовать в выходной спецификации (предложение SELECT). Идентификатор любого упорядочиваемого столбца, который также появляется в выходной спецификации, может быть заменен на его порядковый номер в выходной спецификации при подсчете слева направо:

SELECT EMP_NO, LAST_NAME, FIRST_NAME FROM EMPLOYEE

ORDER BY 2, 3;

Обратите особое внимание на индексы для столбцов, которые будут использованы для сортировки (см. главу 18). Подробнее о синтаксисе и проблемах см. в главе 23.

Его синтаксис:

[FOR UPDATE [OF col1 [,col2..]] [WITH LOCK]]

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

Необязательное внутреннее предложение OF <���список-столбцов> может быть использовано для задания списка присутствующих в курсоре полей, которые могут быть изменены.

* В приложениях ESQL оператор DECLARE CURSOR используется для объявления именованного курсора. Подробную информацию см. в документации по InterBase 6.0 "Embedded SQL".

¦- Приложения интерфейса DSQL должны использовать функцию isc_dsqi_set_ cursor name для получения именованного курсора и осмысленно использовать FOR UPDATE. Более подробную информацию см. в InterBase API Guide.

Поскольку в DSQL отсутствует FETCH как элемент языка, приложения реализуют его с помощью вызова функции API С именем isc_dsql_fetch.