Imam jednostavnu bazu sa poljima: *PROIZVOD, *KOLICINA, *CIJENA, *UKUPNO. Kako da izracunam *KOLICINA x *CIJENA i da se taj rezultat upise u polje *UKUPNO?
Dakle, treba sve biti u okviru samog Accessa.
Pozdrav svima
probaj ovako
UPDATE racunStavka SET ukupno = kolicina * cijena
WHERE id = 1gdje je "racunStavka" ime tablice.
Uvjet prilogadiš svojim potrebama.
pogledaj sljedeći link, možda ti bude koristio
http://www.techonthenet.com/sql/index.php
Moj je prijedlog kolona calculated tipa. Neznam kako se to točno zove i Accessu a riješava ovaj problem gdje bi bio down raditi stalno ovakvo računanje pri svakom upitu a s druge strane raditi kolonu za kako se kaže informaciju a ne podatak - znači nešto što ovisi o drugim vrijednostima te se točno može dobiti iz njih.
Imam jednostavnu bazu sa poljima: *PROIZVOD, *KOLICINA, *CIJENA, *UKUPNO. Kako da izracunam *KOLICINA x *CIJENA i da se taj rezultat upise u polje *UKUPNO?
Dakle, treba sve biti u okviru samog Accessa.
Pozdrav svima
U SQL-u bi bilo otprilike ovako:
Select Proizvod, Kolicina, Cijena, (Kolicina*Cijena) as Ukupno from NekaTablica
Jooooj, pa znaš na što je čovjek mislio... 
Čekaj, nisi za neke izračune (on the fly) i sl?
Ne. Povuci podatke, a poslovnu logiku drži gdje joj je mjesto. Ako trebaš računati u bazi, nešto si zeznuo u dizajnu. Minimalne (!) izračune obavljaš u View/SP... ali obrada podataka mora stati van baze. Ako ti je računanje potrebno za redukciju izlaznog sadržaja, ili imaš loše normaliziranu bazu ili dizajniranu aplikaciju; moraš znati minimum onoga što trebaš.
Naravno, da ne bude zabune, kod velikih količina gdje je potrebno unutar baze presložiti podatke, prebaciti ih negdje ili generirati nove, a izračuni su jednostavni (poput množenja cijena za novu tablicu ili view), stored procedure npr. su bolji izbor nego šetanje hrpe podataka <- samo zbog manjeg izračuna.
Ali bilo što što mora ići van baze, uvijek je bolje u aplikaciji.
I ja isto imam praksu ko Naxeem... pokusavam je koristiti cisto za input/output... kalkulacije obavljam naknadno...
Ne. Povuci podatke, a poslovnu logiku drži gdje joj je mjesto. Ako trebaš računati u bazi, nešto si zeznuo u dizajnu. Minimalne (!) izračune obavljaš u View/SP... ali obrada podataka mora stati van baze. Ako ti je računanje potrebno za redukciju izlaznog sadržaja, ili imaš loše normaliziranu bazu ili dizajniranu aplikaciju; moraš znati minimum onoga što trebaš.
Naravno, da ne bude zabune, kod velikih količina gdje je potrebno unutar baze presložiti podatke, prebaciti ih negdje ili generirati nove, a izračuni su jednostavni (poput množenja cijena za novu tablicu ili view), stored procedure npr. su bolji izbor nego šetanje hrpe podataka <- samo zbog manjeg izračuna.
Ali bilo što što mora ići van baze, uvijek je bolje u aplikaciji.
Gledao sam svojim očima kako je jedan naš domaći SQL MVP nakucao storu za kompletan billing jednog našeg ISP-a... Takva stora je billing obavljala unutar minute, a naša .NET aplikacija je isti posao obavljala oko 30 sati.
Ne mogu vjerovat da je tolika razlika u performansama. Ocekivao bih duplo sporije ali toliko...
Nekada i duže od 2 dana... Pazi, radi se o brdu raznoraznih provjera poslovnih pravila (popusti, odobrenja, storna, akcije, dugovi, uplate, stari računi...). Mislim da je po pitanju optimizacije bilo jako malo mjesta za poboljšanje (u aplikaciji). Sama stora je bila poveća. Mislim da je oko 60-70 kilobajta bila. Nisam vjerovao svojim očima kad sam vidio da se par stotina tisuća računa može napraviti u trenu. Ali onda sam zapravo uvidio da se ipak dosta toga (i to na izuzetno efikasan način) može obaviti na serveru - iako sam do onda bio istog mišljenja kao ti sada.
Ne mogu vjerovat da je tolika razlika u performansama. Ocekivao bih duplo sporije ali toliko...
Kad smo prekucali stari softver na .NET i napravili procedure za prebacivanje svih podataka iz stare baze u novu ostali smo zapanjeni kako to zapravo sporo ide. Prebacivanje je trajalo oko 5 dana. Oni (da ne spominjem ime firme iako možda znate koji su "oni") su kroz storu isti posao napravili unutar sat vremena. Ali, kakva je to stora bila...
Mislim ima logike da ce ici brze jer podaci ne moraju izlaziti vani, ne koriste se nekakve klase koja inace nisu potrebne i slicno... ali nije mi jasno da je tolika razlika u performansama. Susjed mi je u Jadranskom Osig. na bazama... bas cu se malo kod njega raspitat kako oni to tamo rade...
Ma, bilo je puno čimbenika koji su utjecali na to. Milijun CRUD operacija (milijun metaforički), loš menadžment objekata u kodu (aplikacija je žderala masu memorije pa se rušila i svašta)...
Ali da je optimizirano do besvijesti, svejedno je najbrži pristup ipak kad podaci ne idu uopće sa servera.
Ukratko - loš kod.
Inače, baš sam u jednoj raspravi, na jednom socijalnom mediju imao priliku raspravljati koliko je važna kultura kodiranja, arhitektura softvera i kvaliteta samog koda u odnosu na brzinu izrade i 1-goal situacije gdje je taj jedan cilj 'delivery'. Tzv. duct-tape programeri i programiranje su imho štetni, jer se pristupom, kakav je opisan u jednom članku, ignorira sve dobre prakse, pravila dizajniranja softverske arhitekture i patterna razvoja i pisanja koda. Agilni pristup često pogoduje lošem programiranju.
Zašto ovo govorim? - Jer sam pod dojmom da ste i vi taj softver pisali po duct-tape principu "samo da bude gotov" u nekom kratkom roku i da dobrim dijelom iz tog kupusa proizlazi ta enormna razlika u izvođenju i stanje aplikacije koje si opisao.
Sigurno je da je aplikativna obrada sporija zbog transporta, ali toliko? Nemoguće.
Ukratko - loš kod.
Inače, baš sam u jednoj raspravi, na jednom socijalnom mediju imao priliku raspravljati koliko je važna kultura kodiranja, arhitektura softvera i kvaliteta samog koda u odnosu na brzinu izrade i 1-goal situacije gdje je taj jedan cilj 'delivery'. Tzv. duct-tape programeri i programiranje su imho štetni, jer se pristupom, kakav je opisan u jednom članku, ignorira sve dobre prakse, pravila dizajniranja softverske arhitekture i patterna razvoja i pisanja koda. Agilni pristup često pogoduje lošem programiranju.
Zašto ovo govorim? - Jer sam pod dojmom da ste i vi taj softver pisali po duct-tape principu "samo da bude gotov" u nekom kratkom roku i da dobrim dijelom iz tog kupusa proizlazi ta enormna razlika u izvođenju i stanje aplikacije koje si opisao.
Sigurno je da je aplikativna obrada sporija zbog transporta, ali toliko? Nemoguće.
Ta aplikacija je u produkciju puštena u alfa verziji. Da, alfa. Imala je cca 30% potrebne funkcionalnosti kad je uvedena u operativnu upotrebu. Billing engine je bio golema klasa koja je radila sve i svašta ali mislim da je glavni problem bio upravo u nepotrebnim CRUD operacijama. Posebno u gomili (stotine tisuća) select i update radnji nad tablicama koje su debelo premašile 10.000.000 recorda...
