Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Organizacija baze podataka

[es] :: Baze podataka :: Organizacija baze podataka

[ Pregleda: 5351 | Odgovora: 16 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

lare

Član broj: 122678
Poruke: 70
*.PPPoE-4669.sa.bih.net.ba.



+1 Profil

icon Organizacija baze podataka29.08.2007. u 15:14 - pre 201 meseci
Pozdrav svima! Imam programsku podršku za rad marketa u kome postoje 3 kase-računari i 1 server. Trenutno sve četiri kase pristupaju jednoj bazi podataka(MSSQL) koja se nalazi na serveru. Baza podatak između ostalog sadrži tabele Zalihe_robe, Promet_robe, Blok_računa_kupcu. Sa ovakvom organizacijom rad na kasama je prilično usporen. Obzirom da se market proširuje i da se planira uvođenje još 3 kase interesuje me da li postoji neki bolji način organizovanja baze podataka i kako bi se to moglo izvesti? Inače da li je iko upoznat kako to rješavaju veliki super marketi koji mogu imati po 20 i više kasa? Hvala.
 
Odgovor na temu

savkic
Igor Savkić

Član broj: 92186
Poruke: 2739



+92 Profil

icon Re: Organizacija baze podataka30.08.2007. u 23:43 - pre 201 meseci
> Trenutno sve četiri kase pristupaju jednoj bazi podataka(MSSQL) koja se nalazi na serveru. Baza podatak između ostalog sadrži
> tabele Zalihe_robe, Promet_robe, Blok_računa_kupcu. Sa ovakvom organizacijom rad na kasama je prilično usporen.

Ne bih rekao da su te dve stvari u vezi. Najpre niko ti ne može dati odgovor samo na osnovu pominjanja naziva tri tabele iz baze, ako misliš da ti tabele nisu dobro dizajniranje onda daj više detalja, kako sada izgledaju i zašto to misliš. Šta je tačno sporo, koji upiti su spori, kako izgledaju ti upiti, kakav je plan izvršavanja tih upita, mogu li se ti upiti poboljšati, da li se u bazi ili u računaru događaju neke druge operacije koje usporavaju rad, da li je program kasa optimizovan, možda je usko grlo u njemu itd.
 
Odgovor na temu

lare

Član broj: 122678
Poruke: 70
89.146.178.*



+1 Profil

icon Re: Organizacija baze podataka31.08.2007. u 17:37 - pre 201 meseci
Zahvaljujem se na datom odgovoru, a obzirom da nisam bio sasvim jasan, pokušaću da pojasnim o čemu se konkretno radi. Kada se na sve tri kase istovremeno kuca jedan te isti proizvod, na primjer čokolada, sve tri kase će istovremeno izdati zahtjev za pristupanje tabeli Zalihe_robe i željet će da pristupe istom slogu u toj tabeli (polju količina), koja se nalazi na serveru, jer moraju ažurirati broj čokolada koje se nalaze na zalihama. U ovakvom slučaju dolazi do usporavanja rada jer preostale dvije kase moraju da čekaju dok prva kasa ne upiše novu vrijednost broja čokolada u tabelu Zalihe_robe. Nasuprot ovom slučaju postoji tabela Blok_računa_kupcu koja služi za pravljenje računa svakom od kupaca. Za ovakvu tabelu nije neophodno da bude na serveru, jer svaka kasa izdaje zasebno račun i pojedini račun ne zavisi od ostalih računa, što nije slučaj sa zalihama koje se moraju uvijek održavati ažurnim. Moje pitanje bi bilo (obzirom da nemam nikakvog iskustva u radu sa distribuiranim bazama podataka) da li je moguće (i kako) izvršiti distribuciju tabela iz ove jedne baze, koja se sada nalazi na serveru, na više računara? I na kraju opet bi ponovio pitanje iz prvog posta, da li je iko upoznat kako se ovakvi problemi rješavaju u velikim supermarketima sa većim brojem kasa? Opet hvala.
 
Odgovor na temu

Zidar
Canada

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



+79 Profil

icon Re: Organizacija baze podataka31.08.2007. u 19:05 - pre 201 meseci
Mozda bi pomoglo da se stanje ne izracunava stalno? Kasu stanje ne interesuje, kasa samo zeli da zapise negde da je prodata jos jedna cokolada.
Kome treba stanje, kad mu treba, moze da ga izracuna iz razlike ukupnog ulaza i ukupnog izlaza.

Posto je baza na MS SQL, mozda se stanje moze pregledati u nekim intervalima, recimo na svaki sat, ili na svaki minut? Sumnjam da ti trenutmno stanje treba u svakom momentu, s obzirom na velicinu objekta. Ako stanje padne na nulu, to ce se znati i bez kompjutera - nece vise biti cokolada na polici. A i kad spadne na dve cokolade, treba vremena dok se nove naruce i donesu. Sumnjam da u tako maloj radnji neko motri stanje konstantno i da reaguje momentalno. To ni Wal-Mart ne radi. Znaci, iskljucite upisivanje stanja u tabelu i problem resen.

:-)
 
Odgovor na temu

savkic
Igor Savkić

Član broj: 92186
Poruke: 2739



+92 Profil

icon Re: Organizacija baze podataka31.08.2007. u 22:44 - pre 201 meseci
> Kada se na sve tri kase istovremeno kuca jedan te isti proizvod, na primjer čokolada, sve tri kase će istovremeno izdati zahtjev za
> pristupanje tabeli Zalihe_robe i željet će da pristupe istom slogu u toj tabeli (polju količina), koja se nalazi na serveru, jer
> moraju ažurirati broj čokolada koje se nalaze na zalihama. U ovakvom slučaju dolazi do usporavanja rada jer preostale dvije
> kase moraju da čekaju dok prva kasa ne upiše novu vrijednost broja čokolada u tabelu Zalihe_robe.

Ne znam kako si to isprogramirao ali mi ova operacija ne deluje strašno, najpre ne vidim zašto te dve druge moraju da čekaju, svako radi svoj posao a MSSQL i transakcije brinu da sve prođe kako treba. Pre svega ti updejt količina treba da radiš na kraju kada se potvrdi štampanje računa. I updejt radiš tako što se vrtiš u petlji i pozivaš nešto poput: update tabelu set kolicina = kolicina - :prodata_kolicina. Ovo mora da bude brzo, ako nije nešto ne radiš dobro.

Dalje, možda nije neophodno da održavaš ažurne zalihe, već na kraju dana skupiš sve što je prodato pa updejtuješ ili na kraju dana izračunaš karticu artikla pa updejtuješ ili slično. Takođe možeš staviti trigger na stavke računa, pa kada dođe do promene u toj tabeli updejtuješ i zalihe.

> Nasuprot ovom slučaju postoji tabela Blok_računa_kupcu koja služi za pravljenje računa svakom od kupaca. Za ovakvu tabelu nije
> neophodno da bude na serveru, jer svaka kasa izdaje zasebno račun i pojedini račun ne zavisi od ostalih računa,

Blok_racun ti predstavlja stavke računa, to podatke moraš čuvati u centralnoj bazi, barem neko vreme.
 
Odgovor na temu

lare

Član broj: 122678
Poruke: 70
89.146.190.*



+1 Profil

icon Re: Organizacija baze podataka01.09.2007. u 13:34 - pre 201 meseci
Vaša konstatacija je ispravna, ali samo donekle. Ažuriranjem na kraju dana tabele Zalihe_robe može se desiti sljedeća situacija – primjer iz prakse: Sada je u pitanju 'litarsko pakovanje rakije' :-) koje se naručuje od Takova i prodaje u marektu. Stanje na polici na početku dana je bilo 5 litara. Na kraju dana bilo je po računima prodano 15 litara, a na polici nije ostalo ništa. Zaključak je da su radnici sa kase prodavali svoju dobro upakovanu šljivu, a kase nisu ukazale na to jer je na svakoj od njih na početku dana učitano da ima 5 litara rakije na zalihama.

Želio bih opet da napomenem, da trenutno sada, postoji samo jedna baza i da sve tri kase rade samo nad njom. Iz vaših odgovora zaključujem kao da ste shvatili da se radi o distribuiranoj bazi – da svaka kasa posjeduje svoju kopiju baze, međutim to nije slučaj. Također bih mogao da zaključim da bi bilo dobro preći na distribuirane baze, pa bi Vas zamolio da mi kažete, ako znate, za neke dobre linkove o distribuiranim bazama i njihovoj programskoj implementaciji – kao na primjer da li postoji mogućnost kod MSSQL kreiranje neke 'master baze' koja će biti glavna i kreiranje više 'slave baza' koje će se javljati master bazi, a ova u skladu sa potrebama ažurirati ostale baze. Još jednom bi ponovio da nemam nikakvog iskustava u radu sa distribuiranim baza, tako da ako sam u čemu fullo nadam se da nećete zamjeriti. HAVALA!
 
Odgovor na temu

savkic
Igor Savkić

Član broj: 92186
Poruke: 2739



+92 Profil

icon Re: Organizacija baze podataka01.09.2007. u 15:45 - pre 201 meseci
> Stanje na polici na početku dana je bilo 5 litara. Na kraju dana bilo je po računima prodano 15 litara, a na polici nije ostalo ništa. Zaključak je da
> su radnici sa kase prodavali svoju dobro upakovanu šljivu, a kase nisu ukazale na to jer je na svakoj od njih na početku
> dana učitano da ima 5 litara rakije na zalihama.

Radnici će naći način da kradu kako god da okreneš i napraviš sistem, pre svega neće izdati račun ili će dati više puta isti račun (kupac npr. ga ne uzme). Ako se na kraju dana posle updejta lagera primeti da je prodato više nego što ima na stanju, mislim da je stvar vrlo jasna. Kasir će morati da ponudi objašnjenje i još bitnije da pokrije nedostajući pazar.

> Iz vaših odgovora zaključujem kao da ste shvatili da se radi o distribuiranoj bazi – da svaka kasa posjeduje svoju kopiju baze, međutim to nije slučaj.

Ne, jasno mi je da se radi o centralnoj bazi i sve što sam pisao je vezano za rad sa njom.

> Također bih mogao da zaključim da bi bilo dobro preći na distribuirane baze, pa bi Vas zamolio da mi kažete, ako znate
> , za neke dobre linkove o distribuiranim bazama i njihovoj programskoj implementaciji – kao na primjer da li postoji mogućnost kod MSSQL
> kreiranje neke 'master baze' koja će biti glavna i kreiranje više 'slave baza' koje će se javljati master bazi, a ova
> u skladu sa potrebama ažurirati ostale baze. Još jednom bi ponovio da nemam nikakvog iskustava u radu sa distribuiranim baza, tako da ako
> sam u čemu fullo nadam se da

Samo otkucaj Distributed databases na googlu i dobićeš tone linkova. Ponoviću još jedanputa, ne vidim ništa loše u tvom trenutnom sistemu, i sasvim sam siguran da usporenje nije posledica postojanja jedne centralne baze već način na koji radiš. Deljenje baze na svaki računar kasu ti ništa neće doneti a samo će ti otežati posao. Tri kase, 20 ili 50 je sitnica za jedan moderan RDBMS poput MSSQLa.
 
Odgovor na temu

lare

Član broj: 122678
Poruke: 70
89.146.168.*



+1 Profil

icon Re: Organizacija baze podataka02.09.2007. u 12:54 - pre 201 meseci
> Ne, jasno mi je da se radi o centralnoj bazi i sve što sam pisao je vezano za rad sa njom.

Dobro, skontao sam da ste shvatili da se radi o centralnoj bazi podataka, ali ste i Vi i Zidar spominjali periodično ažuriranje centralne baze pa sam zato pomislio suprotno. Vi ste vjerovatno mislili na neku vrstu lokalnog keširanja podataka na kasama (neki xml fajl ili slično) i njihovu offline obradu a zatim da se periodično prelazi u online mod rada. U svakom slučaju hvala Vam na odgovorima i posvećenom vremenu. Poslušat ću vaš savjet i istražiti da se kojim slučajem ne dešavaju neke druge aktivnosti na mreži koje mi usporavaju rad, jer po vašim riječima MSSQL bi trebao lako da podnese 3 ili više kasa. Hvala.
 
Odgovor na temu

chachka
Srđan Mijatov
Programer
BUS Computers
Kikinda

Član broj: 53780
Poruke: 576
*.ADSL.neobee.net.

Sajt: www.baze-podataka.net


+4 Profil

icon Re: Organizacija baze podataka02.09.2007. u 15:45 - pre 201 meseci
Citat:
lare: ... sve tri kase će istovremeno izdati zahtjev za pristupanje tabeli Zalihe_robe i željet će da pristupe istom slogu u toj tabeli (polju količina), koja se nalazi na serveru, jer moraju ažurirati broj čokolada koje se nalaze na zalihama. U ovakvom slučaju dolazi do usporavanja rada jer preostale dvije kase moraju da čekaju dok prva kasa ne upiše novu vrijednost broja čokolada u tabelu Zalihe_robe.

Iz ovoga zaključujem da se proces ažuriranja zalihe vrši na sledeći način:
Code:

1. program->   LOCK TABLE Zalihe_robe

2. program->   SELECT ... FROM Zalihe_robe WHERE ...

3. server->    isporučuje programu informaciju o raspoloživoj količini

4. program->   IF ima_dosta_na_zalihi THEN
                 UPDATE Zalihe_robe SET ... WHERE ...;
                 UNLOCK TABLE Zalihe_robe;
               ELSE
                 UNLOCK TABLE Zalihe_robe;
                 JaviDaZalihaNijeDovoljna;
               END;

Ako sam u pravu, onda ovaj proces zaista dovodi do usporavanja. Da li sam dobro opisao proces ažuriranja zaliha?
"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming."
- Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo
 
Odgovor na temu

dragancesu
subotica

Član broj: 38340
Poruke: 2189
*.eunet.yu.



+73 Profil

icon Re: Organizacija baze podataka02.09.2007. u 16:12 - pre 201 meseci
Prilikom prodaje nema potrebe da konsultujes zalihe, sto ne znaci da ne mozes.

Zalihe su razlika izmedju ulaza i izlaza i po pravilu neko radi ulaz, neko izlaz. Roba je u radnji, kupac stavi u korpu i dodje na kasu. A kasa kaze "NEMA TOGA NA ZALIHI" i ne mozemo vam prodati.

Pomozite Micro$oftu u borbi protiv piraterije, poklonite prijatelju Linux
 
Odgovor na temu

lare

Član broj: 122678
Poruke: 70
*.PPPoE-2021.sa.bih.net.ba.



+1 Profil

icon Re: Organizacija baze podataka02.09.2007. u 17:21 - pre 201 meseci
Citat:
chachka: Iz ovoga zaključujem da se proces ažuriranja zalihe vrši na sledeći način:
Code:

1. program->   LOCK TABLE Zalihe_robe

2. program->   SELECT ... FROM Zalihe_robe WHERE ...

3. server->    isporučuje programu informaciju o raspoloživoj količini

4. program->   IF ima_dosta_na_zalihi THEN
                 UPDATE Zalihe_robe SET ... WHERE ...;
                 UNLOCK TABLE Zalihe_robe;
               ELSE
                 UNLOCK TABLE Zalihe_robe;
                 JaviDaZalihaNijeDovoljna;
               END;

Ako sam u pravu, onda ovaj proces zaista dovodi do usporavanja. Da li sam dobro opisao proces ažuriranja zaliha?



Dobro si opisao proces ažuriranja zaliha, stom razlikom što se zaključavanje vrši na nivou sloga a ne čitave tabele. I ja mislim da ovakav način rada može dovesti do određenog usporavanja, jer druge kase ponekad moraju da čekaju (ako se na svim kasama kuca isti proizvod), ali po riječima uvaženog Savkica 3 ili 20 kasa ne bi trebale da predstavljaju veliko opterećenje za MSSQL. Inače interesovalo bi me tvoje mišljenje/iskustvo o odnosu centralizovane naspram distribuirane baza podataka. Hvala.
 
Odgovor na temu

broker

Član broj: 2415
Poruke: 8514
77.46.253.*



+11 Profil

icon Re: Organizacija baze podataka02.09.2007. u 19:15 - pre 201 meseci
Kao sto ti je rekao dragancesu, nema nikakvog smisl aproveravati zalihe na kasi. Kasa treba da evidentira sav promet, a da li se promet slaze sa zalihama o tome treba da brine neko drugi a ne kasirka ili sama kasa.

Kupac je odsao na kasu, i doneo artikal koji zeli da kupi. ne mislis valjda da kasirka treba daproveri da li tog artikla ima na zalihama pa ako nema, da osrtikal konfiskuje i kupca posalje napolje, a onda digne galamu kako je neko poturio artikal u prodaju?

Nesto ne vidim logiku da zaposleni u prodavnici poturaju svoju robu na rafove a prodaju ih preko kase...

 
Odgovor na temu

zdravcen
Skopje

Član broj: 96284
Poruke: 32
62.162.209.*



+21 Profil

icon Re: Organizacija baze podataka03.09.2007. u 13:19 - pre 201 meseci
Nije mi jasno zasto zakljucavas slog da bi proverio zalihu.
Svaka vrednost koja moze da se izracuna ne treba da se zapisuje u bilo kakvu tabelu.
Provera stanja jednog artikla(saldiranjem ulaza/izlaza) pa koliko god da bili ne bi trebalo da traje duze od sekunde, ako je sve u redu.
A za lager listu i da treba vise vremena(4-5s.) nije kriticna operacija koja se mora odraditi u sekundi.
 
Odgovor na temu

Zidar
Canada

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



+79 Profil

icon Re: Organizacija baze podataka04.09.2007. u 17:11 - pre 201 meseci
Citat:
Stanje na polici na početku dana je bilo 5 litara. Na kraju dana bilo je po računima prodano 15 litara, a na polici nije ostalo ništa. Zaključak je da su radnici sa kase prodavali svoju dobro upakovanu šljivu, a kase nisu ukazale na to jer je na svakoj od njih na početku dana učitano da ima 5 litara rakije na zalihama.


Izgleda da su ovi radnici jako glupi. Ako su prodavali svoju rakiju, i kroz kasu izdavali racune, onda je kasa uknjizila sve te pare i radnici te pare moraju predati gazdi. Ispada da su radnici prodavali svoju lepo upakovanu sljivu, a pare ostavili gazdi u kasi. Svaki gazda bi pozeleo takve radnike :-)





 
Odgovor na temu

chachka
Srđan Mijatov
Programer
BUS Computers
Kikinda

Član broj: 53780
Poruke: 576
*.ADSL.neobee.net.

Sajt: www.baze-podataka.net


+4 Profil

icon Re: Organizacija baze podataka04.09.2007. u 18:52 - pre 201 meseci
@Zidar: Lepo opažanje.

Većina se složila da nema logike da se non-stop vrši ažuriranje količina, ali ja se držim načela: "Nema ničeg logičnog u poslovnoj logici."

Prema tome, ako lare i dalje hoće da non-stop prati stanje lagera, onda mora da skrati vreme u kom je tabela (odnosno jedan red u tabeli) zaključana. Jedino što ja vidim kao rešenje je da se cela logika oko provere lagera izmesti na server i da se na taj način izbegne nepotrebna komunikacija servera i kase.

Postoje dva načina da se opisan proces ažuriranja prebaci na server:
1. upotreba storovane procedure,
2. upotreba trigera.

Po meni je triger elegantnije rešenje pa ću njega i opisati. Napravi se BEFORE INSERT triger nad tabelom Zalihe_robe ovakvog sadržaja:
Code:

LOCK TABLE Zalihe_robe

SELECT ... FROM Zalihe_robe WHERE ...

IF ima_dosta_na_zalihi THEN
  UPDATE Zalihe_robe SET ... WHERE ...;
  UNLOCK TABLE Zalihe_robe;
ELSE
  UNLOCK TABLE Zalihe_robe;
  RAISE EXCEPTION 'Nema dovoljno artikla ...!';
END;

Znači kompletna provera stanja artikla se radi na serveru i izbegnut je mrežni saobraćaj. Ako je zaliha ok ona se update-uje, a ako nije dobra proces INSERT-a se prekida s porukom o grešci.

Program prosto šalje:
Code:

INSERT INTO Promet_robe ...;

Ako je sve u redu ovaj zahtev serveru će proći, a ako nije iskočiće exception.

Što se tiče distribuirano/centralizovano: Problem non-stop ažurirnih količina se može rešiti samo centralizovanom bazom.

Ja nisam radio maloprodajne front/back office sisteme, ali poznajem ljude koji jesu. Mogu da prenesem njihova razmišljanja: Kasa mora biti što više autonomna u svom radu, iz raznih razloga: brzine odziva, problema sa serverom, problema sa mrežom. Autonomna kasa na zahtev servera (odnosno backoffice-a) isporučuje podatke o dnevnom prometu ili po naredbi servera ažurira cenovnik (kojeg lokalno čuva).
"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming."
- Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo
 
Odgovor na temu

franjo_tahi
Franjo Tahi
Zagreb

Član broj: 34712
Poruke: 399
213.147.114.*



+1 Profil

icon Re: Organizacija baze podataka06.09.2007. u 13:05 - pre 201 meseci
Potpuno se slažem s chachka

Na kasi ti trebaju dvije tablice: artikli i promet.
Na početku smjene ili dana učitaš artikle s cijenama
Na kraju smjene ili dana vratiš promet na server.

Program koji se vrti na serveru će ažurirati stanje i napraviti sve ostalo što treba.

Zamisli situaciju: kupac (žena) stane peticom na mrežni kabel. Kasa nema više veze sa serverom! Dok pozoveš majstora koji će to popraviti, prodavać može uzeti slobodan dan :)

chachka je već napisao: što te briga za stanje artikala. Možda je pri unosu robe pogrešno unesena količina... tvoje je da prodaš i napolatiš, a o stanju će brinuti netko drugi.
 
Odgovor na temu

MarkoBalkan

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



+19 Profil

icon Re: Organizacija baze podataka23.09.2007. u 15:48 - pre 201 meseci
obicno su takve baze jako male.
ako je server donekle dobar, radit ce normalno.
stvar je slijedeca.

tri blagajne.
na prvoj teta recimo kuca proizvode.
i odbije se od zalihe, taj komad.
kuca drugi proizvod itd..
i to isto radi teta na trecoj kasi.
e sad kupac moze tako dugo kupovati robu dok je ima.
kad je nema, jednog trenutka ce se pojaviti nula.
ili se moze napraviti da se stavi kontrolno racunalo i napravi programcic koji provjerava broj prodanih komada i od zaliha oduzima broj prodanih komada.
i postavi se neki limit za neke proizvode vise za neke manje.
kad padne zaliha ispod 30 komada, pocrveni u tablici, znaci da je vrijeme za narudzbu slijedeci dan.
time se osigurava da se proizvod dobije na vrijeme.
jer tebe nije briga trenutno stanje nego neka granica ispod koje se neide.
ako padne ispod narucuje se.
a sad koji komad vise ili manje na tu granicu tako nebitno.
i stvar funkcionira.
 
Odgovor na temu

[es] :: Baze podataka :: Organizacija baze podataka

[ Pregleda: 5351 | Odgovora: 16 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.