Koliko sam razumeo ti imas neke vrednosti npr:

stanje = func(a, b, c), gde su a,b,c pretpostavljam neki agregati (npr a = sum(svih promena) from transakcije) iz razlicitih tabela. To je efektivno referential integrity pravilo koje nema direktnu podrsku u SQL-u.


Prvo i najprostije (ali i najlosije) resenje ti je da u stored proceduru i/ili select komandu ubacis nested querije (npr slicno ovom):



Losa strana je sto queri progresivno postaje sve sporiji sporiji kako se Tran tabela uvecava. Drugo, svaki select ce ti baciti shared lockove na sve redove iz Trans koji ucestvuju u agregatu, sto privremeno blokira insert/update komande nad Tran tabelom bez potrebe.


Drugo resenje je upotreba trigera. Znaci zakacis insert/update trigere na tabele koje ucestvuju u a, b, c i na svaki insert/update sracunas stanje i ubacis u Artikal u polja koja pominjes. Ovde samo moras da pazis da trigeri uvek idu istim redosledom u sracunavanju i da koriste table lock hintove u selectima koji racunaju agregate (da bi sprecio drugi triger da umesa prste u racunanje). Iako efektivno i sad lokujes Trans tabelu, to sad radis samo kad dolazi do promene a ne svaki put kad se povuce stanje. Isto vodi racuna da se trigeri ne pozivaju za svaki pojedinacni update, ako se u tabeli jednom komandom modifikuje vise redova, samo jedan trigger ce se opaliti (a inserted i delted implicitne tabele ce imati vise redova, po jedan za svaku promenu). Velika vecina problema koje sam videosa trigerima je sto su developeri pravili trigere kao da se samo jedan red menja/dodaje.


Ono sto sasvim sigurno ne bi trebao da radis je da obezbedjujes referential integrity kroz externe alate (u sta spada i tvoja aplikacija). TO pravi velike probleme sa skalabilnoscu sistema (npr ako se na istu bazu nakaci poseban program koji npr vodi proizvodni proces i vuce materijale iz magacina, i taj program nema pojma da ti vestacki odrzavas stanja van samog SQLa).

Hvala na trudu mmix, ali ne znam jesam li te bas razumio. Sa trigerima dosad nijesam radio, moracu ih malo priucit.

Da ti ja izlozim problem kakav je u stvari, da vidis da nije bas lako.

Imam ulaze i izlaze.

Ulazi mogu biti:
1. Zvanicni i
2. Nezvanicni

Izlazi mogu biti:
1. Zvanicni,
2. Cash i
3. Opet zvanicni (ali mora ici kao posebna vrsta, oni su cilj mome klijentu, preko njega on pokriva ono prodato za kes, mada nije ni bitno u sustini).

E sad Stanje. Ono ima tri kolone:
1. Zvanicno,
2. Fali i
3. Visak.

Evo kako se azurira stanje:

1. Zvanican ulaz povecava kolonu "Zvanicno". Ukoliko je trenutno u koloni "Zvanicno" bila negativna vrijednost, povecati je za iznos koji je u zvanicnom ulazu, ali istovremeno povecati vrijednost kolone "Visak" za onoliko koliko je "Zvanicno" bilo negativno.

2. Nezvanican ulaz samo povecava kolonu "Visak".

3. Zvanicni izlaz smanjuje kolonu "Zvanicno". Ukoliko ce nova vrijednost "Zvanicno" biti negativna, za tu negativnu vrijednost smanjiti kolonu "Visak".

4. Izlaz za kesh smanjuje kolonu "Visak". Ukoliko bi nova vrijednost "Visak" bila negativna, za tu negativnu vrijednost povecati kolonu "Fali". Napomena, "Visak" i "Fali" ne mogu biti negativni (kidaju se negativni djelovi na nulu), dok "Zvanicno" moze ici u minus.

5. Treca vrsta izlaza smanjuje kolonu "Fali", a ako bi ona bila negativna, kolona "Zvanicno" se smanjuje za tu vrijednost. Opet, "Fali" ne moze biti manja od nule.

Eto to su poslovna pravila mog klijenta. Kao sto vidis, potpuno su nelinearna. Akcija koja treba da azurira stanje zavisi od trenutnih vrijednosti u kolonama zvanicno, fali i visak. Mislim, bar ja, da tu uskladistena procedura ne pomaze. Trigeri bi vjerovatno mogli pomoc, pogledacu.

Evo, to ti je kompletan problem, pa mi daj tvoj predlog, ako te uopste volja citat ovo gore.


Pozdrav.

OK, kao prvo, moj najiskreniji predlog je da reorganizujes bazu. Mislim da tacno uvidjam da on insistira na ovom budzenju zato sto radi vele i maloprodaju iz istog magacina a ne uvidja da postoje i lepsa resenja od ove budzevine. On bukvalno simulira maloprodajni magacin preko Fali i Visak polja, gde je zvanicni ulaz u veleprodajni, a nezvanicni ulaz u maloprodajni magacin.
Samim tim moja najiskrenija preporuka je da formiras "virtuelni" maloprodajni magacin u bazi. Znaci dva stanja i mehanizam za presipanje iz jednog u drugi, bilo manuelno, bilo automatski (kad proda nesto za kes prevo prebacis robu u maloprodajni magacin i onda je odmah prodas, znaci ukupno stanje maloprodajnog magacina je uvek nula). Od kad je uveden PDV ovo je postalo dosta lakse za izvesti jer se porezi placaju u oba slucaja i nema komplikovanih procedura knjizenja prebacivanja robe iz jednog u drugi magacin.

Trigeri jesu jedan nacin na koji ovo mozes da resis, ali ovo definitvno moze da se uradi unutar stored procedura za ulaz/izlaz robe i unutar SQL transakcije. Stored procedura ne mora da sadrzi samo pure SELECT/INSERT/UPDATE, mozes da ubacujes i drugi kod za sracunavanje polja i da sve zajedno uokviris u BEGIN TRAN/ROLLBACK/COMMIT strukturu da se osiguras da sve promene udju zajedno ili da ne bude ni jedne, sto tebi ovde definitivno treba.