Правила выбора типа курсора

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

• курсоры базовых таблиц и последовательные курсоры открываются быстрее, чем статические курсоры или курсоры, управляемые набором ключей; внутренние временные рабочие таблицы необходимо составлять, когда статические курсоры и курсоры, управляемые набором ключей, открыты, однако для курсоров базовых таблиц и последоваетльных курсоров они не требуются;

• статические курсоры и курсоры, управляемые набором ключей, увеличивают частоту использования временных баз данных; статические курсоры сервера составляют весь курсор во временной базе данных; курсоры, управляемые набором ключей, составляют набор ключей временной базы данных;

• если базовая таблица извлечена «как есть», без проекции или выбора, рекомендуется использовать курсор базовой таблицы, поскольку он создаёт наименьшую нагрузку;

• статические курсоры используют самое большое количество ресурсов, поскольку они создают копии данных.

В Microsoft SQL Server инструкция SELECT в определении курсора выполняется согласно тем же правилам блокировки транзакций, которыми руководствуются другие инструкции SELECT. Блокировки транзакций, полученные любой инструкцией SELECT, в том числе инструкцией SELECT в определении курсора, управляются следующими элементами:

• настройка уровня изоляции транзакций для подключения;

• любые подсказки блокировки, указанные в предложении FROM.

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

Блокировки удерживаются до завершения текущей транзакции как для курсоров, так и для инструкций SELECT.

Получение блокировок

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

• статические курсоры получают весь результирующий набор при открытии курсора; это блокирует каждую строку результирующего набора во время открытия;

• управляемые набором ключей курсоры получают ключи каждой строки результирующего набора при открытии курсора; это блокирует каждую строку результирующего набора во время открытия;

• последовательные курсоры не получают строк, пока те не будут извлечены; блокировку строки можно получить, только поместив на последнюю курсор.

Приложения могут запросить тип курсора и исполнить инструкцию SQL, которую запрошенный тип курсора не поддерживает. В подобном сценарии Microsoft SQL Server Mobile Edition (SQL Server Mobile) предпримет попытку использовать другой тип курсора, который поддерживает запрошенные свойства курсора. Если такой курсор создать не удастся, будет возвращено сообщение об ошибке.

Неявное преобразование типа курсора

В таблице 8.1. перечислены факторы, инициирующие в SQL Server неявное преобразование типа курсора.

Таблица 8.1.

Факторы, инициирующие неявное преобразование типа курсора

Реквизиты запроса для преобразования	Последовательные и последовательные «только для чтения» курсоры	Курсоры, управляемые набором ключей
В предложении запроса FROM отсутствуют ссылки на таблицы	Становится статическим	Становится статическим
Содержание запроса: Статистические функции списка выбора GROUP BY UNION DISTINCT HAVING	Ошибка	Ошибка
Запрос создает внутреннюю рабочую таблицу. Например, не индексируются столбцы предложения «ORDER BY».	Становится набором ключей	Не используется

Для обновления результатов в приложении Microsoft SQL Server должно быть достаточно сведений, чтобы однозначно идентифицировать строку в таблице.

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

Таблица 8.2.

Факторы, запрещающие обновление результатов с помощью обновляемого курсора

Запрос	Можно ли обновить результаты?
Запрос основан на нескольких необъединенных таблицах	Нет
Запрос основан на системных представлениях	Нет
Запрос основан на таблицах, объединенных соотношением «один-к-одному»	Да. Можно обновить столбцы с обеих сторон. Однако таблицы объединения обновить нельзя.
Запрос основан на таблицах, объединенных соотношением «один-ко-многим»	Да Можно обновить столбцы со многих сторон, за исключением столбцов объединения и удостоверения
Запрос основан на таблицах с соотношением «многие-ко-многим»	Нет
Статистический запрос	Нет
Запрос, содержащий ключевое слово DISTINCT для исключения повторяющихся строк	Нет
Запросы объединения и внешнего объединения	Нет