информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Портрет посетителяЗа кого нас держат?Где водятся OGRы
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





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

это во-первых, некрасиво, во-вторых громоздко смотрится и сложнее отлаживается и, наконец, противоречит самой идее SQL - работы с рекордсетами вместо поочередной работы с отдельными кортежами.
как производители СУБД реализуют работу с множествами, меня заботит мало, гы:) у них конкуренция или как? так пусть же выживут на рынке только те, кто эту фичу реализует наиболее грамотно.
а то на дворе 21 век, а программирование на SQL от клиппера ушло всего на пол-шага:).
<programming> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach