Buduci da su ovo "baze podataka" znaci opste, pokusacu teorijski da ti objasnim.
Triggeri su zapravo 'eventi' tj dogadjaji koji se desavaju u bazi, reakcije, kako bih to nazvao. Znaci kad se desi nesto 'opali' se jedan (ili vishe njih) trigger.
Primjer prije upisa sloga u bazu desava se 'Before_insert" trigger. Kad je record upisan desava se 'After_insert' trigger.
Ono sto si ti u mogucnosti je da zakacis neku proceduru koju ce da pozove odredjen trigger.
Recimo, prije upisa u bazu na trigger 'before_insert' ti provjeravas da li su sva potrebna polja popunjena. Tako izbjegavas recimo da ti baza vraca poruke o greskama i slicno.
Isto tako ako u jednoj detail tabeli promjenis jednu stavku, na trigger After_update ili After_insert imas mogucnost da ponovo izracunas sumu svih stavki i updateujes ukupan iznos u master tabeli.
Postoji jako mnogo triggera, ja sam naveo nekoliko njih.
U zavisnosti od baze mozes ih sam kreirati (koliko se sjecam Oracle moze).

p.s. gore spomenuta imena su vishe opisna.

I jos nesto, pri radu sa (relativno) velikim bazama, treba ih izbegavati

Pozdrav

_{[Ovu poruku je menjao branimir.ts dana 16.11.2005. u 09:07 GMT+1]}

Ovo je velika tema, tako da ne moze sve da se kaze u par recenica. Ono osnovno je da se trigger-i ne pisu u SQL-u nego u nekom proceduralnom jeziku (koji takodje podrzava SQL) koji je malo slozeniji od SQL-a, npr. T-SQL-u (kod SQL Server-a, Sybase-a...) ili PL/SQL-u (kod Oracle-a). Svi oni podrzavaju SQL i u okviru njih se mogu pisati SQL upiti.

Sintaksu za kreiranje trigger-a u Oracle-u mozes da vidis ovde:

http://download-uk.oracle.com/...statements_7004.htm#sthref6117

i tu je sve lepo objasnjeno kako i zasto se koriste trigger-i.



Ovo nije tacno. Naravno da ih ne treba upotrebljavati za svaku sitnicu i u svakoj situaciji, ali nebitno za to da li je baza velika ili ne, neke stvari ce baza (nevezano za velicinu) mnogo brze da odradi, nego da korisnik (ili programer) izvlaci podatke iz baze izvrsava neke operacije nad njima i ponovo ih vraca u bazu.

Pozdrav

Hmm.. , do sada nisam cuo da postoji baza koja "sama odradjuje neke stvari".Sto se tice upotrebe trigera, moj odgovor je jednostavan, i ostace uvek isti. Suvisni su.


SQL nije jezik nego standard, a proceduralni jezici koje navodis su implementacije.

Iskreno, nikad se ne bih usudio ( i nikome ovde to ne bih ni preporucio) da napravi triger AFTER_UPDATE nad tabelom koja ima 100 000 000 slogova (konkretno MSSQL).

Za baze reda tih velicina u multiuser okruzenju diskutabilno je i obicno je stvar procene i iskustva da li treba vrsiti i eksplicitne transakcije, a kamoli trigere.

Pozdrav

SQL = Structured Query Language.
Dakle, to je ipak jezik.
Ne bih rekao da su bas sami po sebi suvisni.

Slazem se da ih treba koristiti u sto manjem broju i da treba paziti gdje ih se smije koristiti, ali neke stvari bez trigera skoro ne mozes ni da zamislis...

Kako bi recimo punio neku increment kolonu ID, ako pri insertu nije poznata/zadana vrijednost tog ID-a? Odgovor - sequence + triger.

Ako zelis da imas neki history log ili monitoring log o vaznim aktivnostima u bazi, onda jednostavno ne mozes bez trigera...

Ja ih ne koristim cesto, pogotovo ne za silne update operacije. Uglavnom ih koristim za te increment kolone sa sekvencama i eventualno nekad za history recorde aktuelnog inserta...

AGAIN:
set @idt = @@IDENTITY
Insert tabela ([ID],.ostala polja) ...@idt..
if (@@ROW_COUNT) <= 0
GOTO AGAIN


Pozdrav



<sub>[Ovu poruku je menjao branimir.ts dana 21.11.2005. u 10:53 GMT+1]

[Ovu poruku je menjao branimir.ts dana 21.11.2005. u 10:58 GMT+1]</sub>

Je l' to za MS SQL, posto nemam pojma sta je tu napisano. :)

Ono za ID sam mislio vezano za Oracle; sorry sto nisam naveo za koju bazu sam mislio...

Ono sto sam napisao je za MSSQL ali manje vise je slicno kod svih savremenih SQL sistema.



Pozdrav

Nije mi jasno zasto pokusavas da izmislis toplu vodu. Ovo je nesto tipa "zasto da bude prosto kada moze da bude komplikovano". Velika vecina programskih jezika podrzava GOTO, ali vidi koliko programera koristi to.



Ne znam kakva iskustva imas sa trigerima pa ih toliko mrzis. Imaju svoje primene i to je sve. I dalje stoji da ih ne treba koristiti za svaku sitnicu, ali imaju svojih prednosti.



Ne znam zasto si imao problema sa ovako necim. Ja nisam imao tabelu koja ima toliko slogova (a i kada sam imao znatno manje tabele, uvek sam ih particionisao tako da je sve radilo najbrze sto je moglo) ali takva neka stvar kod Oracle-a radi normalno (takoreci neprimetno) tako da korisnik nije ni svestan sta se desava iza. Jedino ako ti triger nije radio sa svih 100 000 000 slogova nesto....

Pozdrav

Da se malo ukljucim ...
Trigere na mssql koristim u ne narocito velikoj kolicini (na < 10%tabela).
Posto

pa o ce da pravi problem, ako pravis neki proracun na tih 100M slogova. A isto s***** ce da ti napravi ta operacija ako je startujes sa procedurom, stoga zasto gubiti vreme na komunikaciju sa korisnikom.

Zbilja ne vidim zasto bi trebalo toliko izbegavati kursore, jer mogu biti jako korisni.
Ono sto je problem sto trebaju pazljivo da se koriste. (da en stvaras neke rekurzije i povlacenja pustih slogova bez potrebe)
Takodjer, nema potrebe da se ne koristi triger kod multiuser rada.

Pa, hajde da nastavimo diskusiju.

Nije tacno da ih mrzim, naglasio sam samo da su (po meni, za mene) suvisni.
Obrazlozicu ti zasto tako mislim.
Zamisli jedno okruzenje u kome postoji MSSQL sa tabelama reda velicine 100 000 000 slogova, persistentnih 2000 konekcija na web serveru, c++ servis sa 100 000 threadova od kojih svaki thread izvrsava povremeno (tacno) odredjene akcije nad MSSQL-om (insertuje, brise, updejtuje..itd) , komunicira sa izvesnom kolicinom uredjaja, kao i sa odredjenim brojem posebno napravljenih softverskih modula, web servisima, npr) i tako dalje.

Elem, da se vratim na MSSQL. Sta sve "menja" sadrzaj tabela?
Postoji asp aplikacija koja u izvesnim situacijama "radi sa bazom".
Postoji gore navedeni servis koji radi to isto.
Postoje softverske komponente, web serv koji takodje to rade.
Na sistemu postoji i nekoliko trigera koji s vremena na vreme obrisu izvesnu kolicinu slogova.

Ali, postoje i situacije kada treba debugovati gore navedeni c++ servis. A onda dodje do problema u karakteristicnim situacijama...kako su slogovi nestali "sami od sebe"?Kako je to moguce?...setis se da je bas to uradio trigger, majku mu. Izgubio si pola sata (dragocenog) vremena.



Jesi li to procitao u nekoj knjizi?
Ne vidim ni jedan razlog izbegavanja GOTO direktive , pogotovu ne u SQL implementacijama, odn proceduralnim jezicima.



Slazem se za cursore, apsolutno su korisni.

Pozdrav

Opet ne vidim zasto bi iskljucivo triggeri bili uzroci gubitka slogova? Zar MS SQL nema ROLLBACK, COMMIT, SELECT FOR UPDATE, zatim locking sistem... (tako se zove kod Oraclea, ne znam kako se to zove kod MS SQL-a) ?

Ako se aplikacija (ukljucujuci i triggere) uradi kako treba, tada NE SMIJE doci do gubitka podataka u normalnom rezimu rada.

Konkretno, kada koristis triggere, lockujes taj row gdje je slog i sve dok ne odradis commit te transakcije, izmjene na tom slogu nisu dopustene.

One ASP i C++ aplikacije, koje si naveo, sigurno ne rade sa svih 100 000 000 odjednom. :)
Osim toga, za tako zahtjevne operacije, moras imati i odgovarajuci hardware - viseprocesorske servere sa dooooosta RAM-a, spojene u cluster.
Dakle, da bi obradjivao 100 000 000 slogova u nekom kratkom roku (mislim da si ovaj broj proizvoljno naveo, samo kao pretpostavku), trebas imati stabilan hardware i dobro podesenu bazu sa stabilnom aplikacijom.

Tada ti nijedan trigger nece postavljati veliki problem. :)
Naravno, niko nije lud da postavlja trigger, koji ce raditi update ili delete na vecem broju slogova ( > 1000 npr.).

Zamislio.
I sta sad?

A zamisli ti ovakvu situaciju

Imas gomilu tabela na SQL Serveru u kojima je jako bitan integritet podataka (mada, nema takve baze kod koje nije bitan, bar bi trebalo da je tako) Ti kao DBA ces se verovatno odluciti da celu poslovnu logiku strpas u bazu a ne da krparis sa nekim devetim layer-om po redu koji ce izvrsavati neki residentan program/servis. Sad dolazis u situaciju da jedino preko trigera mozes to da uradis i sta ces odluciti. Pa nema druge nego da kreiras iste.
Ako su trigeri najpogodniji za datu situaciju implementiras ih a ako ne odbacujes ih i trazis drugo resenje. Univerzalno resenje ne postoji. Ne mozes reci trigeri su losi samo zato sto su za tvoj slucaj losi.

Nisi me razumeo. Naravno da pri debagovanju nikada ne dodje do gubitka neophodnih slogova.
Problem je sto uvek "razmisljas" o 1000 drugih mogucih uzroka "naprasnog nestanka specificnih slogova" (govorim o sasvim karakteristicnim postupcima pri debagovanju c++ servisa), da bi na kraju ustanovio da si pokrenuo akciju koja je upravo "naterala" trigere da obrisu par slogova.Problem je u gubitku vremena, ne u gubitku podataka.



Uredjivanje gore pomenute baze je jedan jako dobro isplaniran i smislen proces, koji se odvija u tacno definisanim vremenskim intervalima.

Pozdrav

Ne znam kakve si ti perverzije izvodio sa triggerima, ali u mom dosadasnjem iskustvu stvarno nikad nisam imao problema sa triggerima...

A radim na bazama od Telekoma Austria, pa zamisli koliko su ceste i brojne izmjene u silnim tabelama i o kojem broju istovremenih konekcija se radi...

Kazem ti lijepo, ako dobro uradis aplikaciju i ugradis mehanizam za ROLLBACK i COMMIT, mala je vjerovatnost da ces imati nekih problema sa triggerima. Ako se i desi neki error exception, lijepo rollbackujes transakciju i nastavis dalje, bez gubitka ikakvih podataka...

Postoji jos jedna stvar u vezi trigera na MSSQL u.
Naime, cini mi se da su malo "skriveni" i nisu ocigledni kao ostali objekti u bazi.

Pozdrav

Mozda ne kontam.. ali branimir kaze da ti triggeri brishu svako-toliko neke slogove??
Pa valjda onaj koji radi na toj bazi, tj aplikacije koje pristupaju istoj i ko je postavio te triggere tu, valjda ih je stavio sa razlogom. Znaci da ti triggeri rade svoj posao i ima nesto za sta oni brinu. I sad ti pravis novu app, a ne znas kako funkcionishe stara i zaboravis na postojanje triggera?? To je tvoj propust, a ne losha strana triggera.
To sto nisu vidljivi u MSSQL ne znaci da su loshi nego je opet do tebe sto ne obracas paznju na njih, jer ih vjerovatno ti nisi stavio.

Moram da se ispravim, mislio sam na triggere, a ne na kursore, kursore u principu izbegavam

Ako nemas naviku da koristis kursore onda koriscenje moze da predstavlja problem.
u biti predstavljaju odlicno ubrzanje u obradi podataka.

Jedini problem koji sam imao sa kursorom jeste da sam jednom "ispustio" triger iz skripta, kreirao bazu i pustio u rad, koja nije htela da se azurira pravilno. problem otkriven u roku od par min.

Nije mi potpuno jasno o čemu se radi. Da li koristiti trigere? U svakom slučaju da, pitanje je samo za što. Ja ih obavezno korsitim za kreiranje primari key-a (ako nemam neki suvisli podatak za to) npr: ID koji je autoincremental. Puno manje, ali ih ipak koristim kod preračunavanja nekih sumarinh stavki da bih ubrzao kasnije preglede, ali nikada na više od 10-tak slogova kojiko ih ima jedna primka ili otpremnica.
OVako radim dugo i na dosta baza i do sada zbog toga nisam imao problema.

Hoce li neko objasniti sta to znaci da su trigeri skriveni na MSSQL Serveru?

A zar nije bolje resenje koristiti GUID, nego incremental ID?

GUID je OK, ali autoincremental ima prednost što znam redosljed dodavalja slogova, a bez uvođenja polja datetime. Zbog administriranja mi je nekada bitan redosljed, pa da ne bih imao malo GUID, malo autinc. zato koristim samo autoinc.
Trigeri su veći problem za kasnije održavanje i izmjene programa koji su na bazama, a ako ga radi netko drugi, a ne onaj tko je napravio program - u velikim bazama se lako previde.

Kakva je to prednost?

Preko auto incrementa ne mozes znati tacan redosled izmene slogova.

Na MSSQL se za takve stvari koristi binarno polje tipa timestamp.

Pozdrav

Da se i ja malo ukljucim u raspravu. U firmi u kojoj radim se slabo koriste ali ipak koriste okidači. Moj savet je: očuvanje integriteta baze je uvek na prvom mestu bez obzira na sve. Postoje stvari koje se jednostavno drugačije ne mogu rešiti (tada treba koristiti okidače) u suprotnom izbegavati ih.

Sad se setih R.Viera je u knjizi "Professional SqlServer 2000" poglavlje koje se bavi okidačima započeo nesto ovako (izvinjavam se zbog eventualnih gresaka u citatu, davno sam to čitao): "Okidači su dobri, okidači su korisni i okidači su vaši prijatelji. U isto vreme okidači okidači su ruzni, okidači su zli i okidači su vaši najgori neprijatelji."

Šta više reći??

A što se auto incrementa tiče zašto ne koristiti IDENTITY polje umesto da se kodira u okidačima?

Cao, ja sam pocetnik u sql...i pokusavam da razumem sta su tacno transakcije? Negde sam shvatila da se vec postojeca baza menja,prilikom transakcija i da te akcije su izolovane...ali nisam najsigurnija..ako moze neko s lepim primerom da mi pojasni tacno sta je i kada je potrebna?

Pozdrav!

Sa Wikipedije, prvi link koji daje Krgovićev link ;)



Pogledaj komande COMMIT i ROLLBACK, a ima i drugačijih, sve je dato u linku.


Ukratko, transakcija je grupa operacija nad bazom, sa idejom "sve ili ništa". Ako su sve operacije izvrsene OK, onda se stanje baze stvarno i menja (COMMIT). Ako makar jedna operacija nije prosla kako treba, baza ostaje kava je i bila, nepromenjena (ROLLBACK).

Moja ideja je bila da @neki_adsl pokaze malo truda, procita, eventualno skine neku free bazu (postgre, mysql, sta god), proba elementarno i pita KAD ZAPNE, kad ne razume i kad pokaze elemntaran trud ulozen u razumevanje, pre pitanja na forumu.

Hvala vam :) @nkrgovic ...probala sam sve to :) imam mysql instaliran, zajedno sa javom to ucim. Jednostavno nisam razumela...i cini mi se da nije toliko opste pitanje,da sam npr pitala sta je SQL e onda jbg :) . @X Files znaci to je grupacija akcija u kojoj sve akcije moraju da budu uspesne da bi promene bile permanentne? Jel moze da se desi npr da imam neku grupaciju akcija, tipa unos podataka u bazu,izmena podatka..a da se te dve akcije ne smatraju transakcijom?

Naravno, elementrani iskazi tipa INSERT, UPDATE ili DELETE nisu sami po sebi transakcije, korisntiš ih po želji.

E to je mene zbunjivalo,mislila sam da je onda sve transakcija...danak neiskustvu :) . A evo jos jedno pitanje xD , da li index moze da bude primary key? Npr ja sad imam artikl s sifrom 34...da li bi bilo besmisleno staviti unikatan index 1 na taj artikl? Kad vec on sam ima tu sifru?

- Ako drugacije nije postavljeno, elementarni iskazi tipa "INSERT...." jesu transakcije, u smislu da ce, ako insert iz nekog razloga pukne biti uradjen rollback, zapravo si dobro shvatila. Cilj transakcije je da napravi grupu izjava koje, delimicno izvrsene nemaju smisla, tj. napravice stanje koje logicki nije ispravno, tako da developer moze da garantuje da ce one biti izvrsene u paketu, tipa "Sve ili Nista".

Dodatne prednosti mogu da budu vezane za optimizacije storage engine-a, tj. internog rada baze. Ako pustis par stotina UPDATE statementa kao transakciju mozes usput reci bazi (ili moze ona sama, mozda, ako je dovojlno pametna) da ne radi update index-a posle svakog UPDATE-a, vec samo jednom, kad se transakcija zavrsi. Ako update-ujes par hiljada slogova u tabeli od par miliona i gde svaki update traje zbog regenerisanja index-a, dobices znacajno ubrzanje operativnog rada.

- Primary key mora da bude non-null i unique. Ako ti tvoj index sasvim sigurno to obezbedjuje logicki je sasvim ispravno da ga stavis kao primarni kljuc. S'druge strane, nije besmisleno uvesti unikatan dodatni slog, neki "ID", tipa integer, autoincrement koji ce da bude primarni kljuc, stavise dobra ti je logika.

Prednost je sto npr. bas mysql koristi primarni kljuc za replikaciju, tako da mu bas prija da bude integer. S'druge strane, ako tvoj index (sifra proizvoda, sta god), nekad bude morala da iz netehnickih razloga bude varchar (videces vremenom, imaces glupe zahteve), taj ALTER ce ti posle napraviti veliki problem.

Takodje, svi indexi koje mysql pravi (dodatni indexi), kao prvo polje imaju primarni kljuc - ako ga ti ne stavis, on ga nalepi implicitno, jer mu treba. Samim tim, ziva je zgoda da to bude prosto integer a ne neko duze polje. Iz tog, i nekih drugih razloga, sve InnoDB tabele MORAJU da imaju primarni kljuc, vodi racuna o tome. Ako ga nemaju, opet, mysql ce ga napraviti implicitno. Ako ne moze da ga identifikuje (nema odgovarajuceg polja), napravice kompozitni, nekad od SVIH polja zajedno - i onda em to update-ovati svaki put, em to lepiti na sve ostale indexe. Sustina je: Uvek imaj primarni kljuc, kao ID, integer.

Konacno, cisto napomena: Ako stavis primarni kljuc neki ID, koji je autoincrement, baza ce ti garantovati da se inkrement svaki put inkrementira. Nece ti garantovati da je taj inkrement tacno 1 niti za koliko raste - samo da raste. Postoje razlozi vezani za replikaciju kad je meni ovo bas trebalo, tako da vodi racuna kako razmisljas i sta ti jeste a sta nije garantovano. :D

Kad lepo pitas i pokazes ama bas malo truda, odma vecini nije tesko da se potrudi i objasni ti sve sto moze. :D

U pravu si! Kada sam ono gore napisao, razmišljao sam da li da objašnjavam baš to što si napisao, ali nisam hteo da komplikujem i dodatno zbunjujem ("kako sad to, kada nema reči TRANSACTION") ;) U svakom slučaju, dobro je da je i to sada izrečeno...


@neki_adsl
Uvek otvori novu temu za novo pitanje, da se tema ne pretvori u Chat room :)