Citat:
Mozda nisam najbolje objasnio pa da se popravim...
Kolicinu ulaza i ulaznu cijenu pamtim u jednoj tabeli tblUgovori
Kolicinu izlaza i izlaznu cijenu pamtim u drugoj tabeli tblRacunStavke
Hjeo bih da ne upisujem stalno cijenu izlaznu u tblRacunStavke nego da je za izvjestaje vucem iz cjenovnika.
Napravio sam tabelu tblCjenovnik koja je u vezi sa tabelom tblSifarnik...jedna Sifra artikla moze imati vise cijena, ali je samo jedna cijena aktuelna u momentu prodaje (datum i vrijeme).
Nemogu nikako skontati kako da napravim da mi query vuce odgovarajucu cijenu koja je vazila u momentu prodaje.
Ova recenica
Citat:
Nemogu nikako skontati kako da napravim da mi query vuce odgovarajucu cijenu koja je vazila u momentu prodaje.
je razlog sto se u 99.99% slucajeva u praksi vodi samo jedan cenovnik, sa tekucom cenom, a cena se prepisuje iz cenovnika u tabelu tblRacuniStavke. Ja bih to nazvao 'jednostavni cenovnik'. Na taj nacin imas u tabeli tblRacuniStavke cenu koja je vazila u u momentu prodaje (upisivanja u tabelu tblStavkeRacuna). To jeste na neki nacin dupliciranje podataka, ali su zato kveriji mnogo jednostavniji. To je primer razumne denormalizacije baze.
Ako bas zelis da vodis cenovnik sa vremenskom komponentom, tako da se u cenovnik upisuje
(Artikl, Cena, DatumOdKogaVaziCena),
kveriji se znatno komplikuju. To bih nazvao 'cenovnik sa vremenskom komponentom'. Potpuno te razumem kad kazes
Citat:
Dakle veza postoji preko tabele tblRacun (DatumRacuna), ali mi je komplikovano napraviti taj parametarski upit koji ce mi vuci cijenu ciji je datum racuna izmedju Datuma VaziOd i VaziDo, a ako se cijena nije nikako mijenjala onda je ona cije je polje VaziDo Is Null.
Vise ne gledas direktno u ceo cenovnik, nego izvlacis iz cenovnika samo one redove ciji DatumOdKogaVaziCena odgovara datumu prodaje. Sta ovo znaci?
Neka je datum racuna 10 Mart 2009. Neka imas u cenovniku za odrdjeni artikl ove unose:
Tabela tblCenovnikKrozVreme
ArtiklID Cena DatumOdKogaVaziCena
7 12.5 1 Jan 2008
7 18.5 30 Jun 2008
7 16.5 30 April 2009
7 22.5 30 May 2010
Za tvoj datum 10 mart 2009 treba uzeti cenu koja je vazila vazi od 30 Juna 2008 - ocigledno iz tabele. kako u kveriju da dodjem do ovog datuma? Pa to je maximalni datum u tabeli tblCenovnikKrozVreme koji je manji od datuma na racunu. Drugim recima,
za svaki artikl pogledaj u sve redove u tblCenovnikKrozVreme gde je DatumOdKogaVaziCena <= tblRacun.datumRacuna i onda uzmi najveci od njih. To je cena koja vazi za dat artikl na datom racunu. Nadam se da si shvatio logiku. Sad samo treba napisati kveri koji tu logiku realizuje.
Ako bi nam zakacio bazu sa tabelama tblCenovnikKrozVreme, tblRAcuni, tblStavkeNaRacunu, napisao bih ti kveri koji ovo radi. Kveri nije jednostavan, jer je u stvari to correlated subquery. To nije jednostavno za pisanje u Accesu. Dodatno, takvi kveriji se uglavnom izvrsavaju sporo. To bi mogao biti jedan od razloga sto ovaj metod nije bas uobicajen u praksi. Medjutim, kad ti resenje treba za jedan odredjeni racun, moguce je ubrzati ceo proces, pomocu nekih sitnih trikova. Za konkretan kveri zakaci bazu pa da probamo. Pa ako bas bude nedopustivo sporo razmislicemo o trikovima za ubrzanje.
A ti na kraju odluci sta ti se vise dopada:
a) metod prepisivanja tekuce cene iz prostog cenovnika u stavke racuna, ili
b) metod vodjenja cenovnika sa vremenskom komponentom
a) je klasican metod, siroko rasprostranjen. b) je torijski bolje resenje, ali se nekoristi u praksi dovoljno dugo da bi se steklo neko siroko iskustvo. Ja kod jednog klijenta koristim ovaj metod, ne za cenu nego za neke druge stvari promenljive kroz vreme, i mogu da kazem da radi. Sporije jeste, ali
nije nedopustivo sporije.
Sve u svemu ovo ide u prilog mom zapazanju da se u bazama podataka stvari komlikuju za bar jos jedan red velicne, kada se u igru uvede vreme. Negde sam procitao da za to sluze normalne forme viseg novo, 5. i 6 cini mi se, mozad gresim. U svaom slucaju, stvari se komplikuju. Pa sta ako se komplikuju, to odvakja profesionalca od amatera i dunstera
Zakaci test bazu pa da probamo, ako hoces.
Praćenje cijene kroz vrijeme
Re: Praćenje cijene kroz vrijeme