insert taktika ako slog mozda vec postoji

Dvoumim se oko sledeceg:
treba uraditi insert u tabelu pri cemu odgovarajuci slog moze vec postojati u toj tabeli (PK). Znam dva nacina da to uradim:
1. "slepi" insert sa exception-om
2. prvo select da proverim da li vec postoji PK i uradim insert "na sigurno".
Pitanje je sta je bolje, ako uopste postoji razlika?
Moje misljenje je da pri "slepom" insertu baza ionako vrsi tu proveru pa je exception koji vraca kao da sam sam uradio proveru, pri cemu valjda baza to radi brze i spretnije... Da li ima neki dodatni overhead?
Inace, kod se nalazi u trigeru koji puni neku vrstu sifarnika i pretpostavka je da ce se relativno retko pojavljivati "novi", tj. da ce se cesce desavati da vec postoji odgovarajuci slog nego da zaista treba uraditi insert.

Pogledaj oracle-ovu "merge" komandu mozda moze da resi to sto zelis
Pozz

Hvala na odgovoru, pogledao sam MERGE, odlicna je funkcionalost! Da sam znao ranije, iskoristio bih je pri inicijalizaciji i verovatno izbegao insert sa NOT IN komandom. Ali imam dva problema sa koriscenjem MERGE-a trenutno:
- ne treba mi "bulk" unos, ovo se u trigeru desava 1 na 1 (ili 1 na 0), pa mi se cini da je ova komanda "preteska" za tako nesto
- nije ista sinitaksa za 9.1 i 10.2 a imamo korisnike sa obe verzije baze pa to znaci dve varijante trigera
Ja sam u stvari problem vec resio (vec sam i pustio triger korisnicima) nego me zanima koja je od dve gorenavedene tehnike bolja za ovakvu vrstu posla?

Ako nije u pitanju bulk insert vec povremeno insertovanje nekoliko slogova u neki sifarnik onda necemo osetiti nikakvo poboljsanje performansi pa ne bih to ni razmatrao pogotovo sto to radis nekim jednostavnim triggerom koji proverava postojanje neke unique vrednosti nad indeksiranom kolonom (PK). Generalno ono sto se zove dobra praksa je da pises jasan kod a ne da logiku rada zasnivas na internom exception-u koji ce podici baza, takodje takav prenos kontrole u exception sekciju moze da zakomplikuje stvari mozda ne u ovom tvom slucaju ali generalno u slozenijim obradama da. Na kraju zamisli sutra da jos neko drugi treba da odrzava taj kod trebao bi da razmislja sta je pesnik hteo da kaze, onda makar eksplicitno uvati DUP_VAL_ON_INDEX i to je bolje nego varijanta 1.

Pozz!

Hvala na odgovoru. Sto se tice zamisljanja nema sta da zamisljam :) mi vec imamo interne dogovore oko pisanja koda i slicno... DUP_VAL_ON_INDEX jeste ono sto sam mislio pod jedan. Pokusavam da optimizujem jer je baza inace opterecena svime i svacime, pa se svaka usteda racuna, a insert se nece bas desavati "povremeno" nego verovatno vrlo cesto i triger se nalazi na veoma prometnoj tabeli.

Moje se pitanje odnosilo na to da li je "jeftinije" da sam proverim da li postoji vec PK (dakle potreban mi je jedan select u internu promenljivu) ili da to prepustim bazi? Dakle da li je
select ... ; if ... then insert ... ; bolje ili gore od
insert ... ; exception ... ;

U prvom slucaju imam select "viska". U drugom slucaju imam exc. za koji nisam siguran koliko kosta. Cini mi se da je druga varijanta svakako bolja ako procenim da ce se cesce desavati da insert prodje (sto trenutno nije slucaj). A inace se, cini mi se, ovde treba odluciti izmedju select-a i exception-a.

Sto se tice prenosa kontrole u exception, slazem se da to moze biti losa praksa, posebno ako taj exception sadrzi brdo komandi. U ovom slucaju, naravno, to ne igra neku ulogu.
Uostalom i to se moze izbeci time sto bi se u slucaju exception-a (bilo da se radi o sistemskom ili user exc.) podigao neki interni flag kojim bi se kasnije izvrsio prenos kontrole na odgovarajucu granu programa.

Razumem sta si pitao ali odgovor koji trazis da li ce te vise kostati prvo ili drugo ne moze tako lako da se da bez malo detaljnijeg poznavanja dizajna i logike sta se sve tu kod tebe desava. Znaci opet dobra praksa je ako u nesto nisi siguran uraditi merenje. Ono sto mogu da ti preporucim je da u oracle-u 10g imas sql tuning i sql access advisor pa pokusaj da simuliras situaciju i vidis kakav je npr. ukupan uticaj na DB time u tvojoj varijanti 1 pa onda u varijanti 2
pozz!

Pa to sam i mislio, da je to neko izmerio :) Ok, hvala na odgovoru, ako budem nasao ili izmerio sta je bolje, postovacu to ovde...
Pozdrav.