[ chemical brother @ 27.01.2012. 11:47 ] @
Pozdrav svima,

situacija je sljedeća:

Imam proceduru koja sadrži kursor, koji prolazi kroz neki result set i treba da te podatke importuje u drugu tabelu.
Međutim, neke kolone se ne upisuju direktno, nego je potrebno na osnovu vrijednosti u njima, otići u drugu tabelu i na osnovu te vrijednosti povući, recimo, ID.

Može se izvesti podupitom, može se izvesti JOIN-om, ali me neko upita zašto ne napraviti proceduru koja bi to provjeravala, pa da je u osnovnoj proceduri
pozivam kad treba.

Pitanje glasi: koliko je ovo loša ideja (lično pretpostavljam da je loša), jer osnovna tabela može imati nekoliko stotina zapisa, to je isto toliko poziva procedura?

Ako neko može da mi podrobnije objasni šta se dešava ispod haube kad se iz jedne procedure poziva druga, koliki je udar na performanse, i na kraju koliko je to dobar/loš programerski pristup :)

[ Zidar @ 27.01.2012. 17:35 ] @
Neam nikakvih problema da procedura poziva proceduru. Problem je kursor sam po sebi. A ako bi kursor jos pozivao proceduru u svakom pomeranju to je onda gore.

"Imam proceduru koja sadrži kursor, koji prolazi kroz neki result set i treba da te podatke importuje u drugu tabelu." Ovde verovatno kursor uopste i ne treba.

Imas u prethodnoj temi, ispod ove, veliku istinu koju je rekao D. Kondic
Citat:
Kursor je uvek loša ideja tako da kursor u kursoru predstavlja lošu ideju na kvadrat.


[ mmix @ 27.01.2012. 17:47 ] @
Pa zavisi od prirode iteracija

moze da bude i nlog(n) losa ideja
[ HladankaoLed @ 29.01.2012. 21:34 ] @
Citat:
Zidar: Neam nikakvih problema da procedura poziva proceduru. Problem je kursor sam po sebi. A ako bi kursor jos pozivao proceduru u svakom pomeranju to je onda gore...


Ajd sad kad je i ala i vrana udarila po kursorima da kazemo i nesto u njihovu odbranu... :)

Kursori su losi i performanse resenja na bazi kursora su gotovo uvek losije od resenja koja pocivaju na set pristupu. Ali nisu uvek.

Jedna od retkih prilika gde su performanse kursor resenja bolje je racunanje running totalsa ili running aggregatesa. (Izvinjavam se zbog kombinovanja srpskog i engleskog; boojim se da bi prevod na srpski izgledao jos rogobatnije). Tu je kursor bolji zbog kvadratne slozenosti subquery ili join algoritama, pa je za veci broj rekorda kursor ne samo brze resenje nego i jedino moguce. Detaljnu analizu uradio je Itzik Ben-Gan u SQL Server Magazinu pre neku godinu.

Nazalost po kursore, a na veliko zadovoljstvo svih ljubitelja window funkcija i ovo poslednje uporiste pada u SQL Server 2012 verziji. DBEngine je doradjen, tako da se running totalsi racunaju elegantno i veoma brzo koriscenjem window funkcija.

Elem, da neko ovu "odbranu" kursora ne shvati pogresno. Ako ne racunate running total onda je upotreba kursora za resenje Vaseg problema los izbor; gotovo uvek je moguce isti problem resiti primenom set logike. SQL Server je optimizovan za tu logiku i razlike u performansama su katkad ogromne.

Pozdrav,
M.
[ Zidar @ 31.01.2012. 14:44 ] @
HladanKaoled, lepo receno.

Evo i od mene jedan link na clanak na SQL Central, gde Jeff Moden demonstrira jedno ndeokumentovano resenje za running total koje je mnogo brze cak i od kursora. Zbog toga sto s eoslanja na nedokumnetovane metode, clanak je izazvao interesantnu diskusiju. Preporucujem da se prodje kroz diskusiju, jer neki od najvecih mozgova u SQL zajednici ucestvuju i imaju sta da kazu. Obratite paznju na ime Alexander Kuznetsov. Upozorenje, nije za pocetnike :-)

http://www.sqlservercentral.com/Forums/Topic802558-203-3.aspx

:-)

[ HladankaoLed @ 08.02.2012. 11:07 ] @
Citat:
Zidar: HladanKaoled, lepo receno.

Evo i od mene jedan link na clanak na SQL Central, gde Jeff Moden demonstrira jedno ndeokumentovano resenje za running total koje je mnogo brze cak i od kursora. Zbog toga sto s eoslanja na nedokumnetovane metode, clanak je izazvao interesantnu diskusiju. Preporucujem da se prodje kroz diskusiju, jer neki od najvecih mozgova u SQL zajednici ucestvuju i imaju sta da kazu. Obratite paznju na ime Alexander Kuznetsov. Upozorenje, nije za pocetnike :-)

http://www.sqlservercentral.com/Forums/Topic802558-203-3.aspx

:-)


Hvala na linku, Zidar.

Zaboravio si jednu veoma vaznu napomenu u vezi sa navedenim topicom, pa da onda ja upozorim community...

Ako se neko odluci na citanje, neophodno je da prethodno uzme godisnji odmor :)

Poz,
Milos