Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
да нет тут подводных камней. 13.02.03 18:43 Число просмотров: 1032
Автор: йцукенг <jcukeng> Статус: Member
|
> Всё-таки у курсоров есть куча всяких параметров, в MS SQL > они довольно быстрые, ага, быстрые.
пока нет транзакций:)
допустим, у тебя есть таблица "клиент" и в ней миллион записей.
ты хочешь в транзакции пробежаться по всем записям и для малой части из них (в зависимости от результата, возвращаемого некоторой хранимой пр-рой) вызвать какую-то другую хранимую процедуру.
если хоть один вызов второй процедуры завершился с ошибкой, нужно сделать откат транзакции.
а вот что происходит в действительности: такой курсор заблокирует нафиг всю таблицу и фактически все клиентские процессы, пытающиеся получить доступ к этой таблице, зависнут, пока не завершится транзакция [либо пока таймаут не произойдет):]. как правило, при использовании курсоров по таким большим таблицам происходит переполнение transaction log'а и вся база гикается со страшным свистом.
чтобы избежать или хотя бы уменьшить вероятность возникновения подобной ситуации, приходится делать выборку во временную таблицу ID-ов записей удовлетворяющих критерию отбора,
потом делать begin tran, открывать курсор, и бегать им по временной таблице, вызывая втоhую процедуру, закрывать курсор и далать commit.
это во-первых, некрасиво, во-вторых громоздко смотрится и сложнее отлаживается и, наконец, противоречит самой идее SQL - работы с рекордсетами вместо поочередной работы с отдельными кортежами.
как производители СУБД реализуют работу с множествами, меня заботит мало, гы:) у них конкуренция или как? так пусть же выживут на рынке только те, кто эту фичу реализует наиболее грамотно.
а то на дворе 21 век, а программирование на SQL от клиппера ушло всего на пол-шага:).
|
|
|