Citat:
Cudna je stvar, trazio sam od tebe da opises tvoj nacin rada ali nisi to uradio, umjesto toga negiras nacin koji sam ja uradio ne upustajuci se u problematiku.
To vec spada u domen izrade projekta aplikacije. Ovo o cemu sam pisao je
samo princip rada kod odredjivanja sta se gde cuva od podataka. I to nije
samo teorija vec je praksa uveliko. Moram te podsetiti da je osnovno
pravilo kod izrade baza podataka da se nigde ali bas nigde ne cuva ono sto
moze biti izracunato u realnom vremenu.
Citat:
Necu da negiram tvoj nacin, koji si opisao ali kazes da uzimas cijenu koja je najvazniji o datumu, a ne kazes dali tu iskalkulisanu cijenu uopste zapisujes i gdje ili je dobijas racunskim putem.
Podseticu te da sam napisao da su kalkulacija i nivelacija dokumenti koji
odredjuju cenu proizvoda, pa je logicno da tamo i treba da budu sacuvanai a
da se upitom uzima cena koja je najsvezija po datumu za formiranje lagera.
Citat:
Ako budemo trazili na izlazu (ili kako ti kazes posaljes upit) zadnju kalklaciju te novoformiranu cijenu te stanje tog artikla itd.. sto nam treba da vidimo u izlazu onda je upitno koliko ce to brzo raditi a tu nam je najpotrebnija brzina i efikasnost i na kraju krajeva tu imamo i najvise upisa u bazu.
Tu se potpuno slazemo da je potrebna brzina pri radu sa kasom. Ali ako imas
kasu koja jedna i povezana direktno na bazu onda se da pretpostaviti da je
i promet na toj kasi relativno mali. Racunari su dovoljno brzi da mogu da
sazvacu kompletnu obradu, sve se svodi na upit koji vraca samo jedan
podatak i to je uvek dovoljno brzo. Cim je broj kasa veci ili se
postavljaju i drugi zahtevi onda se kasa i ne povezuje sinhrono na glavnu
bazu pa ni na glavni racunar. Sve podatci, a to su uglavnom cenovnik i
izdati racuni , cuvaju se u samoj kasi i tek na zahtev salju se serveru
baze podataka.
Program pisan na ovaj nacin radi u praksi. Do sada nisam imao nekih
primedbi. Najveca firma koja radi na ovaj nacin ima nekih 40 000 artikala
sedam veoma posecenih i dislociranih poslovnih celina veleprodaje i svaki
od tih centara opsluzuje dosta maloprodajnih objekata sto svojih , sto
komotenata. Aplikacija je pisana u Accessu ali je server baze SQL Server
2000. Svi VP objekti su sinhrono povezani na glavnu bazu preko ADSL i
jedino sto je morao da se napravi kompromis kod formiranja lagera. U toku
noci, pre pocetka rada napravi se tabela tblLager koja sluzi kao polaz i
onda se upitima dodaju i pridruzuju dokumenti koji su u toku dana izazvali
promenu kolicine i cene robe. To je sve sto se tice principa rada.
@Izonic:
Nadam se da ti je malo vise pomoglo u razumevanju prethodnih postova.
Pozdrav