Читать онлайн «Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ». Страница 84

Следующий простой пример иллюстрирует группирующий запрос. Агрегатная 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 <предикат-группирования>

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

По умолчанию UNION убирает дубликаты в финальном выходном наборе. Для сохранения всех дубликатов добавьте ключевое слово ALL[71].

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

PLAN <выражение-плана>

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

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

ORDER BY <список-столбцов>

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

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

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

[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.

API "знает" порядок и формат выходных полей, потому что динамическое приложение должно передавать ему описательную структуру- называемую расширенной областью дескрипторов SQL (Extended SQL Descriptor Area, XSQLDA). Одна структура XSQLDA содержит массив описателей сложных переменных, называемых SQLVAR, по одному на каждое выходное поле.

Клиентское приложение использует isc_dsqi_fetch для запроса строки, которая только что заполнила XSQLDA. Обычное поведение большинства современных клиентских приложений- выполнение в цикле обращений к isc_dsqi_fetch для получения выходных строк в пакете и буферизация их в структурах клиентской стороны, которые называются наборами записей, наборами данных или результирующими наборами.

Некоторые приложения API реализуют именованные курсоры и используют поведение TOR UPDATE, однако большинство этого не делают.

Вложенное предложение WITH LOCK

Firebird 1.5 вводит необязательное расширение WITH LOCK, используемое с/без предложения FOR UPDATE, для поддержки ограниченного уровня явной пессимистической блокировки (pessimistic locking) на уровне строки. Пессимистическая блокировка является прямой противоположностью архитектуры транзакций в Firebird и добавляет запутанность. Ее использование рекомендуется только тем разработчикам, которые хорошо понимают, как параллельная работа многих пользователей реализована в Firebird. Пессимистическая блокировка обсуждается в главе 27.

Среди некоторых программистов существует закрепившаяся практика разработки приложений, которым нужно выполнить подсчет строк в выходном наборе. В Firebird не существует быстрого надежного способа получения количества строк, возвращаемых в выходном наборе. Поскольку Firebird имеет многоверсионную архитектуру, у него нет механизма "узнавать" количество строк в постоянных таблицах. Если приложению требуется количество строк, оно может получить приблизительное значение с использованием запроса SELECT COUNT (*).

Запросы SELECT COUNT(*)

Оператор SELECT с вызовом функции COUNT() на месте идентификатора столбца вернет приблизительную мощность набора, определенного в предложении WHERE. Функция COUNT() принимает практически все в качестве входного аргумента: идентификатор столбца, список столбцов, символ *, который представляет "все столбцы", и даже константу.

Например, все следующие операторы эквивалентны или близки. При этом SELECT COUNT(<имя-некоторого-столбца>) не включает в счетчик строки, где <имя-некоторого-столбца> имеет значение NULL:

SELECT COUNT (*) FROM ATABLE WHERE COL1 BETWEEN 40 AND 75;

SELECT COUNT (COL1) FROM ATABLE WHERE COL1 BETWEEN 40 AMD 75;

SELECT COUNT (COL1, COL2, COL3) FROM ATABLE WHERE COL1 BETWEEN 40 AND 75;

SELECT COUNT 1 FROM ATABLE WHERE COL1 BETWEEN 40 AND 75;

SELECT COUNT ('Sticky toffee') FROM ATABLE WHERE COL1 BETWEEN 40 AND 75;

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

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

Исключением является ситуация, когда COUNT (*) включается в выходной набор, который агрегируется на основании предложения GROUP BY. При этих условиях счетчик не будет дорогим - он будет рассчитываться для агрегированной группы в процессе выполнения агрегирования. Например: