@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