i dalje mi se ne svidja :) no vec je mnogo bolje
* tip_sata
sta ti je sad ova tabela? tip_sata tabela po meni treba da bude "konfig" tabela, dakle da ima
tip_sata_id (int)
aktuelno (enum:jeste|nije)
naziv (char)
pocinje (time)
zavrsava (time)
index_cene (decimal)
vikend (enum:da|ne) -- ovde bi moglo cak da bude pon(enum), uto(enum)... sub(enum), ned(enum) ali moze i ovako
datum_aktivacije (datetime)
i to je sve. I to ti je konfig tabela, u njoj ti za svaki tip sata pise kad pocinje, kad se zavrsava i index cene. npr:
1, nije, "normalan sat ", 07:00.00, 14:59.59, 1.0, ne, 01.01.1945
2, jeste, "normalan sat ", 09:00.00, 16:59.59, 1.0, ne, 01.01.2000
3, jeste, "nocni overtime ", 00:00.00, 08:59.59, 2.0, ne, 01.01.2000
4, jeste, "nocni overtime ", 21:00.00, 23:59.59, 2.0, ne, 01.01.2000
5, jeste, "obican overtime ", 17:00.00, 20:59.59, 1.5, ne, 01.01.2000
6, jeste, "vikend overtime ", 00:00.00, 23:59.59, 3.0, da, 01.01.2000
onda imas zasebnu tabelu gde imas "vrednost sata" i gde cuvas promene u ceni sata kroz vreme .. a pravu cenu sata racunas kao trenutnu cenu sata u toj tabeli * index_cene iz tip_sata
onda ti sihtarica detalji ima smisla. Ti si nakrcao sadrzaj cele tabele u jedan rekord trenutno + sta ce ti radnik_id u tip_sata? eventualno tip_sata moze da ima radnik_TYPE_id, pa da razlicit tip radnika ima razlicite indexe i razlicito da mu se racuna overtime, tako da recimo imas neki "prosecan sat" koji kosta recimo 50$ pa sljaker ima index za normalan sat 0.5, manager ima index za normalan sat 1.0, sef otseka ima index 2 a dba ima index 5.0 na primer .. mada je to redak slucaj i tako se radi uglavnom samo po drzavnim firmama gde se plata dobija po ceni radnog sata koja je ista za sve, u normalnim firmama ti dogovaras tu cenu individualno tako da ti za obracun treba koliko ima sati (izmnozeno sa indexima za tip sata) a onda se to pomnozi sa dogovorenom cenom sata "za tebe"
Projekat modelovanja baze od nule do finalnog resenja
Re: Projekat modelovanja baze od nule do finalnog resenja
