Можно ли решить данную конкретную задачу с помош;ью временной таблицы?

Не лучше ли будет вариант, в котором требуемые действия полностью осуществляются в клиентском приложении?

Напомним, что СУБД SQL Server сохраняет набор данных для статического курсора в одной из собственных таблиц базы данных tempdb. А если так или иначе этот набор данных сохраняется средствами SQL Server, то почему бы разработчику самому не воспользоваться такой временной таблицей? Но дело в том, что иногда попытка применения временной таблицы вместо курсора не позволяет получить требуемые результаты (обеспечить построчную обработку, а не вьшолнение операций с множествами). Тем не менее, если в приложении требуется всего лишь получить снимок данных, относящийся к какому-то моменту времени, а не обеспечить вьшолнение операций с отдельными строками, можно создать отдельную временную таблицу, используя оператор SELECT INTO, и устранить в своих интересах (и в интересах СУБД SQL Server) много дополнительных издержек.

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

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

Вначале сформируем таблицу, предназначенную для проведения экспериментов, затем создадим курсоры различных типов и проведем с ними эксперименты для ознакомления с их функционированием. USE AdventureWorks

/* Создается таблица, с которой будут проводиться эксперименты в этот раз */

SELECT SalesOrderlD, CustomerlD

INTO CursorTable

FROM Sales.SalesOrderHeader

WHERE SalesOrderlD BETWEEN 43661 AND 43665

-- Объявление курсора DECLARE CursorTest CURSOR

GLOBAL -- Параметр, позволяющий манипулировать курсором из

-- кода, находящегося за пределами данного пакета

SCROLL -- Параметр, позволяющий выполнять прокрутку назад

-- и проверять результаты внесения изменений

STATIC -- Параметр, проверяемый на этот раз

SELECT SalesOrderlD, CustomerlD FROM CursorTable

-- Объявления двух вспомогательных переменных DECLARE ©SalesOrderlD int

DECLARE ©CustomerlD varchar(5)

-- Открытие курсора и получение первой строки OPEN CursorTest

FETCH NEXT FROM CursorTest INTO ©SalesOrderlD, ©CustomerlD

-- Обработка данных в цикле WHILE @©FETCH STATUS = О BEGIN

PRINT CAST(©SalesOrderlD AS varchar) + + ©CustomerlD FETCH NEXT FROM CursorTest INTO ©SalesOrderlD, ©CustomerlD

-- Внесение изменения. Вскоре будет показано, что это изменение не влияет на -- работу курсора UPDATE CursorTable

SET CustomerlD = -111

WHERE SalesOrderlD = 43663

-- Проверка содержимого таблицы для определения того, действительно ли в ней

-- произошло обновление

SELECT SalesOrderlD, CustomerlD

FROM CursorTable

-- Переход в начало набора данных. Это возможно, поскольку курсор является -- прокручиваемым

FETCH FIRST FROM CursorTest INTO ©SalesOrderlD, ©CustomerlD

-- Повторная обработка в цикле

WHILE @@FETCH STATUS=0

BEGIN

PRINT CONVERT(varchar(5),©SalesOrderlD) + + ©CustomerlD FETCH NEXT FROM CursorTest INTO ©SalesOrderlD, ©CustomerlD

-- Удаление ненужных объектов CLOSE CursorTest

DEALLOCATE CursorTest

DROP TABLE CursorTable

Ниже приведены первые полученные при этом результаты (следует отметить, что автор ввел в действие опцию Results in text , чтобы упростить просмотр результирующих наборов и формируемых в связи с их получением сообщений PRINT).

(5 row(s) affected)

43661 442

43662 227

43663 510

43664 397

43665 146

(1 row(s) affected) SalesOrderlD CustomerlD

43661 442

43662 227

43663 -111

43664 397

43665 146

(5 row(s) affected)

43661 442

43662 227

43663 510

43664 397

43665 146

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

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

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

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

Ключевые курсоры

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

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

Должно соблюдаться обязательное требование, согласно которому на рассматриваемой таблице должен быть задан уникальный индекс.

В базе данных tempdb хранится только набор ключей, а не весь набор данньгх.

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

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

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

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