Citat:
Bilo bi jos bolje kad bi se taj update radio automatski, odnosno kad bi se nove cene preuzimale iz najnovije nivelacije (da se gleda po datumu). Da li je moguce ovaj problem sa updateom cena nekako resiti bez mnogo uplitanja sgl-a?
Ovde imamo dva dobra zapaznaja:
1) "bilo bi dobro... kad bi se nove cene preuzimale iz najnovije nivelacije (da se gleda po datumu)"
i
2) " Da li je moguce ovaj problem sa updateom cena nekako resiti bez mnogo uplitanja sgl-a"
Resenje je moguce, i celo je u SQL, to jest na nivou tabela. Nemam sad vremena, sutra cu postaviti primer gde se prati promena cene za artikle o datumima. Pre nekoliko nedelja bila je prica o pracenju zauzetosti kamiona mislim, gde smo objasnili prinicipe pracenja promena kroz vreme. Ima dva dugacka PDF dokumenta, ne secam se tacno kako se zvala tema, neka mi neko pomogne.
Sutra cu da postavim primer pracenja cene kroz vreme,. Stos je u neocekivanoj upotrebi PK i FK. Zahteva minimum programiranja na unosu, na recimo BeforeUpdate za tabelu u kojoj se cuva promana cene i to je sve. Pokazacemo i kako se pisu kveriji koji povezuju transakcije - stavke sa cenama koje su vazile na odredjeni dan. A onda vi dodajte na to sta treba za nivelaciju. U nivelaciju se ne razumem.
Pokuascu ako stignem da pokazem i cuvanje stanja u tabeli. Jeste., znam,"cuvati stanje u tabeli nije normalizovano i ne trebastanje da se cuva u tabeli, treba racunati stanje kad ti zatreba". Posto se to ipak radi u praksi, a moze da bude i korisno, da barem pokazemo kako se to PRAVILNO radi. Poznavanje stanja u svakom momentu verovatno moze da pomogne sa nivelacijom...
:-)