Почитал тут про курсоры в MSSQL...
Получается, что курсоры - это всего лишь средство удобной работы с результатом выполнения запроса. Т.е. возможность делать частичные выборки из этого большого результата.
Первый абзац про курсоры из MSDN:
Цитата:Operations in a relational database act on a complete set of rows. The set of rows returned by a SELECT statement consists of all the rows that satisfy the conditions in the WHERE clause of the statement. This complete set of rows returned by the statement is known as the result set. Applications, especially interactive online applications, cannot always work effectively with the entire result set as a unit. These applications need a mechanism to work with one row or a small block of rows at a time. Cursors are an extension to result sets that provide that mechanism.
Больше всего с точки зрения сабжа меня интересуют "динамические курсоры":
Цитата:Dynamic cursors reflect all changes made to the rows in their result set when scrolling through the cursor. The data values, order, and membership of the rows in the result set can change on each fetch. All UPDATE, INSERT, and DELETE statements made by all users are visible through the cursor.
После прочтения мануала складывается следующее впечатление. ODBC-провайдер для ТП является рукопашной реализацией обычного динамического курсора MSSQL. Т.е. вместо того, чтобы использовать API сервера для получения небольшой порции данных одного большого запроса при помощи курсоров, в провайдере используется имитация этого API при помощи генерации отдельных запросов. Соответственно, вопрос: "зачем?" Т.е. чем использование запросов оказывается лучше для решения задачи?
Динамические курсоры не требуют больших затрат ресурсов сервера. Например, никак не задействуется tempdb, как это происходит в статических курсорах. Не происходит задействование больших объемов памяти на клиенте, как это происходит в случае клиентских курсоров. Динамические курсоры всегда получают обновленные данные, если данные поменялись другими пользователями.
"Нежелательные артефакты", которые некоторые получают при использовании курсоров, скорее всего, объясняются "неправильным приготовлением" курсоров, т.к. курсоры - всего лишь средство получить часть выборки большого запроса. Т.е. пока у меня возникает впечатление, что использование курсоров
функционально эквивалентно ручному получению нужных частей большой выборки при помощи запросов.
Грубо говоря, получается, что в ODBC-провайдере "изобретен велосипед" вместо использования готовых средств сервера. Почему? Чем это вызвано? Я вижу только одну причину. Провайдер может работать с разными ODBC-драйверами. В том числе и для таких СУБД, которые не поддерживают серверные курсоры. Но эта причина не является аргументом против курсоров и эта причина не является аргументом в пользу превосходства "подхода запросов" над "подходом курсоров". Вывод: не получим ли мы какие-либо выгоды, создав провайдер, специально заточенный под курсоры MSSQL? Например, ускорение работы или упрощение организации провайдера?
Очень интересует мнение людей, имеющих хорошее представление о курсорах (как минимум, хорошо изучивших документацию
) Интересует, насколько хорошо работают курсоры. Какую нагрузку создают на сервер? Удобнее ли они запросов? Удобны ли они вообще в использовании? Может, их использовать настолько сложно, что лучше использовать запросы? Вообще, интересен любой практический опыт работы с курсорами.
Страницы: 1
MSSQL: курсоры vs запросы для работы с ТП (число прочтений - 6168 )
