[ peromalosutra @ 24.01.2013. 21:08 ] @
Pitanje nije usko vezano za MySQL, vec za relacione baze generalno, ali mislim da cu ovdje rasprava biti zanimljivija. :)

Radi se o odnosu izmedju predstavljanja stanja na racunu, transakcija sredstava izmedju racuna i stepena normalizovanosti baze. Recimo da treba da imam bazu korisnika, gdje svaki korisnik ima svoj racun. Korisnik moze da uplacuje sredstva na racun, kao i da placa odredjene usluge uplacenim sredstvima. Transakcije izmedju racuna nisu moguce (mada mozemo razgovarati i o tome). Koji je najbolji nacin predstavljanja ovoga u relacionoj bazi?

Teoretski, dovoljno je da za svakog korisnika pratimo transakcije koje pravi. Uplatu na racun predstavimo pozitivnim iznosom, a isplatu negativnim, konacna suma predstavlja trenutno stanje na racunu. Medjutim, buduci da je trenutno stanje nesto sto se cesto koristi, onda je korisno cuvati i ovu vrijednost, pa ju nakon svake transakcije preracunavati.

Jedan od pristupa bi mogao biti:

1. tabela account_states (account_id, user_id, state)
2. tabela account_transactions (transaction_id, user_id, service_id amount, timestamp)
3. tabela services(service_id, name, description)

Da li update stanja raditi na aplikativnom nivou, ili na nivou baze (triggeri)? Znam da konkretna implementacija zavisi od konkretnih zahtjeva, ali me zanimaju neki druge ideje i iskustva.

[ bogdan.kecman @ 25.01.2013. 13:58 ] @
Citat:
peromalosutra: ali mislim da cu ovdje rasprava biti zanimljivija. :)


zasto?
na opstem rdbms forumu ima mnogo vise ljudi sa iskustvom koji bi mogli da diskutuju na tu temu

Citat:
peromalosutra:
Radi se o odnosu izmedju predstavljanja stanja na racunu, transakcija sredstava izmedju racuna i stepena normalizovanosti baze. Recimo da treba da imam bazu korisnika, gdje svaki korisnik ima svoj racun. Korisnik moze da uplacuje sredstva na racun, kao i da placa odredjene usluge uplacenim sredstvima. Transakcije izmedju racuna nisu moguce (mada mozemo razgovarati i o tome). Koji je najbolji nacin predstavljanja ovoga u relacionoj bazi?


nisam siguran da ima potrebe izmisljati toplu vodu, to sto si naveo je klasican "bankarski racun" (stanje, primas pare, saljes pare) ... ima na netu nekoliko primera organizacije baze podataka za banku, pogledas, ukrades ...

pogledaj npr: http://www.information-management.com/issues/20020701/5339-1.html

takodje pogledaj kako se to radi sistemski, vecina velikih sistema to ima dokumentovano, urado pretragu za "SAS Detail Data Store for Banking" na primer


Citat:
peromalosutra:
Da li update stanja raditi na aplikativnom nivou, ili na nivou baze (triggeri)? Znam da konkretna implementacija zavisi od konkretnih zahtjeva, ali me zanimaju neki druge ideje i iskustva.


ja licno smatram da to danas treba da radi application layer i da trigeri treba da se koriste samo pri odrzavanju raznih intermediate tabela za razne reporte ali da sama biznis logika mora da bude u app layer-u a nikako na db-u (triger, stored procedure ..) no to je moje misljenje i sa njim se mnogo ne slazu (i daju validne argumente zasto ja mozda nisam u pravu, no ja imam svoje argumente koji su meni bitniji od tih drugih .. svako mora da odluci za sebe)
[ bogdan.kecman @ 25.01.2013. 13:59 ] @
obrati paznju da je kod takvih sistema uvek bitnije da imas sigurnost i tacnost nego brzinu!!