[es] - Dilema, sto mislite da je bolje?

Mikelly

Član broj: 16730
Poruke: 240
85.94.116.*

Profil

^{10.10.2007. u 09:30}

Ovako, radim jednom poznaniku malu bazicu za robno knjigovodstvo.

Sad me interesuje kako da postavim bazu.

Naime, on ima oko 500 artikala, ulaze artikala (povecavaju trenutno stanje) i izlaze artikala (smanjuju trenutno stanje).

Da li mi je pametnije da prilikom svakog ulaza/izlaza modifikujem stanje, ili
da prilikom prikazivanja stanja izracunavam to stanje kao SUM(ulaz) - SUM(izlaz), po artiklu, naravno.

Cini mi se da je drugi slucaj ispravniji jer je manja mogucnost greske, ali moze da bude spor ako ima dosta zapisa.

Sto vi mislite?

^{10.10.2007. u 09:30}

misk0
.: Lugano :. _.: CH :.

SuperModerator
Član broj: 634
Poruke: 1910
*.adsl.ticino.com.

ICQ: 46802502

Profil

Re: Dilema, sto mislite da je bolje?

^{10.10.2007. u 10:46}

Vec je pisano o tome po forumu, potrazi.

U sustini imas u upotrebi obe metode. U svakom slucaju moras pamtiti ulaze i izlaze u vidu ulaznih i izlaznih dokumenata. Ima smisla da updateujes tabelu artikala sa stanjem pa onda svako toliko napravis obradu i poravnanje sa stvarnim stanjem. U zavisnosti od prometa, znaces koliko cesto ces raditi te izracune.

:: Nemoj se svadjati sa budalom, ljudi cesto nece primjetiti razliku ::

^{10.10.2007. u 10:46}

Zidar
Canada

Član broj: 15387
Poruke: 1692
*.100.46-69.q9.net.

Profil

Re: Dilema, sto mislite da je bolje?

^{10.10.2007. u 16:01}

Zavuisi koga pitas. Ako pitas knjigovodje i ljude koji su radili robno knjigovodstvo pre nego su relacione baze uvedene u upotrebu, reci ce ti da se absolutno mora izracunavati stanje prilikom svake transakcije. Razlog - pre relaqcionih baza bilo je veoma tesko doci do stanja na osnovu uporedjivanja ulaz i izlaza, ponekad i nemoguce. Stoga je imalo smisla stalno azurirati stanje, pa kad nam zatreba - tu je. Od kako su uvedene relacione baze, stanje je moguce dobiti iz kverija u bilo kom momentu. Ali, neki se plase da ce kveri biti spor.

Da bi kveri postao spor, potrebno je mnooooogo rekorda (meri se milionioma ili desetinama miliona) ili jako aljkavo projektovana baza. Slucaj mnoooogo rekorda se na javlja tako cesto u praksi. Slucaj aljkavo projektovane baze se desava kad neko bez iskustva ili sa pogresnim iskustvom projektuje bazu. neko ko je navikao da izracunava stanje, mozda ce projektovati bazu tako sto ce preslikati COBOL ili Dbase tabele u tabele na nekom SQL serveru i dobiti opet sporu bazu. Time ce se dokazati da su kveriji spori i da nema nista bolje od izracunavanja stanja. Nista lakse, sad imamo i trigere koji to mogu da odrade efikasno, mi smo programeri i volimo da programiramo :-)

Ucini sto ti je srcu drago.

:-)

^{10.10.2007. u 16:01}

MarkoBalkan

Član broj: 141124
Poruke: 486
*.adsl.net.t-com.hr.

Profil

Re: Dilema, sto mislite da je bolje?

^{11.10.2007. u 14:38}

a kako se onda u praksi rjesava sporost izvrsenja querya?
ako recimo imamo 300 tablica, i 50 tablica sadrzi preko 1 milijon redaka.
a nama recimo treba upit u realnom vremenu tj. da je izvrsenje maximalno 10 minuta.
znam , sad ce netko reci stavi se jaci server, ili ne znam sta.
ako ovih 300 tablica stavimo na server sa 8 GB rama, i recimo 4 dvojezgrena procesora.
dali bi ovo radilo?
sad ce opet netko reci ovisi o strukturibaze.sto je tocno.rcimo da zanemarimo strukturu.

Edit: Obrisan je nepotreban citat

_{[Ovu poruku je menjao chachka dana 11.10.2007. u 16:02 GMT+1]}

Često sam padao na ispitima, Proklete stolice!
Mogao sam biti car!

^{11.10.2007. u 14:38}

jablan
Mladen Jablanović
Beograd

Član broj: 8286
Poruke: 2995
194.228.230.*

Sajt: blog.radioni.ca

Profil

Re: Dilema, sto mislite da je bolje?

^{11.10.2007. u 14:41}

Citat:

MarkoBalkan: sad ce opet netko reci ovisi o strukturibaze.sto je tocno.rcimo da zanemarimo strukturu.

Jednostavno, ne možeš zanemariti strukturu.

_{Probajte Ruby}

^{11.10.2007. u 14:41}

MarkoBalkan

Član broj: 141124
Poruke: 486
*.adsl.net.t-com.hr.

Profil

Re: Dilema, sto mislite da je bolje?

^{11.10.2007. u 20:10}

a kako se onda postupa u takvim situacijama?
kad imamo puno veza, relacija, itd...

recimo malo sam testirao i do 100000 sa dvije tablice radi dosta brzo.
ali kad bude vise tablica, vise relacija. vise redaka, onda nije ni jednostavno za napraviti da radi brzo.

jer kazem idealno vrijeme izvrsavanja querya bi bilo ispod kakvih 5 minuta.
sve sta je iznad 5 minuta je dugo, a kamoli pola sata ili sat.
pa tko ima vremena cekati pola sata da se izvrsi jedan query, a tamo jos ceka 10 komada na red.

Često sam padao na ispitima, Proklete stolice!
Mogao sam biti car!

^{11.10.2007. u 20:10}

misk0
.: Lugano :. _.: CH :.

SuperModerator
Član broj: 634
Poruke: 1910
*.adsl.ticino.com.

ICQ: 46802502

Profil

Re: Dilema, sto mislite da je bolje?

^{11.10.2007. u 20:15}

Imas jedan query koji ukljucuje 50 tabla po milion slogova? Nesto nije u redu sa arhitekturom....

:: Nemoj se svadjati sa budalom, ljudi cesto nece primjetiti razliku ::

^{11.10.2007. u 20:15}

MarkoBalkan

Član broj: 141124
Poruke: 486
*.adsl.net.t-com.hr.

Profil

Re: Dilema, sto mislite da je bolje?

^{11.10.2007. u 20:26}

ne to.
npr.imam 300 tablica.
50 tablica ima 1000000 redaka.
recimo trebam query koji izbacuje neko prebrojavanje po artiklima ili tako nesto.nije bitno sad.
ali cinjenica je da su sve tablice vezane.
ako imamo 50 tablica, i radimo query, za to bi trebalo jako dugo vremena da se izvrsi.
moje je pitanje kad se pojavi ovakav problem , na koji se nacin rjesava u praksi.

Često sam padao na ispitima, Proklete stolice!
Mogao sam biti car!

^{11.10.2007. u 20:26}

Getsbi
Miroljub Zahorjanski
Vršac

Član broj: 124608
Poruke: 1153
91.150.115.*

Profil

Re: Dilema, sto mislite da je bolje?

^{11.10.2007. u 20:55}

To što su ti tabele uvezane je samo kvalitet više. Query može po strukturi imati i veći broj tabela u sebi (mada bi broj 50 što reče misk0 govorio o lošoj arhitekturi modela). Nije presudan toliko ni broj redova. Ono što je bitno za brzi rad query-a je da ti u tabelama budu ideksirana polja koja učestvuju u kriterijumima pretrage query-a.

I'll know what I want, when I see it.

^{11.10.2007. u 20:55}

zmau
Dragan Jovanović

Član broj: 80834
Poruke: 137
195.46.55.*

Sajt: www.jovanovic.fotopic.net

Profil

Re: Dilema, sto mislite da je bolje?

^{22.10.2007. u 17:44}

A kada radiš u stvarno velikom sistemu i dođeš do cifri koje pominješ (mada ni ja ne verujem u smislenost upita nad 50 tabela), onda se uvode druga oruđa u igru. Možeš da imaš rezervnu kopiju baze nad kojom će se izvršavati ti besni sintetički upiti. A recimo svake noći radiš sinhronizaciju (ne ti, server radi svake noći :) ) produkcione baze i baze za izveštaje (koja usput može biti i sigurnosni bekap). A i postojanje 2 baze doprinosi rasterećenju. Ili imaš par dodatnih tabela stanja koje ti služe za izveštavanje, i opet svake noći server žvaće podatke za njih. A u tim sintetičkim izveštajima - veruj mi - nije bitno da imaš baš stanje od ovog trenutka, dovoljno je dobro i stanje od noćas.

Naravno, sve ovo ti ne radi posao ako hoćeš bukvalno da vidiš ima li artikla na stanju da bi ga prodao čoveku, ali za tu situaciju sigurno nećeš imati više od 4-5 tabela u upitu.

Kada ni ovi koncepti nisu dovoljno dobri, u priču uleće OLAP (guglaj). I baze koje nisu relacione nego svojom strukturom (takozvane kocke) prilagođene intenzivnom čitanju.

^{22.10.2007. u 17:44}

Getsbi
Miroljub Zahorjanski
Vršac

Član broj: 124608
Poruke: 1153
77.46.165.*

Profil

Re: Dilema, sto mislite da je bolje?

^{22.10.2007. u 18:57}

Mislim da su većini sa ovog foruma (ili bar većini učesnika ove teme) poznati modeli dimenzionih baza podataka sa postupcima denormalizacije, tabelama dimenzija, tabelam činjenica, data mining metodom za analizu podataka, ali takođe mislim da smo malo otišli predaleko sa savetovanjem u zadnjih par postova jer je ipak pokretač teme na početku rekao da se radi o manjoj bazici za robno knjigovodstvo sa oko 500 artikala.

I'll know what I want, when I see it.

^{22.10.2007. u 18:57}

Miloš Baić

Član broj: 72468
Poruke: 1089
*.kalik.info.

Sajt: www.2advanced.com

Profil

Re: Dilema, sto mislite da je bolje?

^{23.10.2007. u 12:23}

Po mom mišljenju i 5 minuta za izvršenje nekog SQL upita je puno, s osvrtom na problematiku koju je pokretač teme postavio.

Složiću se, kao što je neko rekao, da u tom slučaju baza nije dobro projektovana i da se struktura nikako ne može zanemariti.

Elem, za problematiku koju je Mikelly naveo, stanje u magacinu, dovoljno je par dobro oranizovanih tabela, jedna optimizovana procedura koja će se izvršiti na nekom od servera za bazu, te vratiti set podataka koji ćemo gledati, štampati, etc. Taj proces ne bi smeo da traje duže od par sekundi, mada u nekim slučajevima je i to mnogo.

If you go out of your mind, do it quietly, so as not to disturb those around you...

^{23.10.2007. u 12:23}