Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ
вернуться

Борри Хелен
Шрифт:

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