Säg att vi har en användare som är anställd vid företaget X. Han får en grundlön på 120:-, vardagar efter 19.00, lördagar efter 12.00 och hela söndagar får han dessutom OB-tillägg på 100% (lönen är med andra ord 240:- under dessa tider). Tanken var nu att användarna själva ska kunna ställa in hur mycket de får i lön, och under vilka tider de får OB.
Fråga 1:
Hur bygger man bäst upp databasstrukturen här? Funderade lite och kom fram till nedstående:
id - primärnyckel
workid - Arbetsplatsens ID
userid - Användarid
salary - Lön
weekday - Veckodag (1= måndag, 7 = söndag osv.)
starttime - F.r.o.m. vilken tid på den veckodagen som lönen gäller
stoptime - T.o.m. vilken tid på den veckodagen som lönen gäller.
Tanken var då att användarens grundlön sparas i en post där weekday = NULL, starttime = NULL, stoptime = NULL. Sen får man lägga till fler poster (ex. en med weekday = 6 (lördag), starttime = 12.00, stoptime = 23.59, salary = 240:- och en med weekday = 7, starttime = 00.00, stoptime = 23.59 samt salary = 240:-) för alla tillfällen där lönen avviker från grundlönen. Sen skulle man då med någon smidig sql-sats kunna kontrollera om aktuell tidpunkt har något OB-tillägg, eller om det är grundlönen som gäller. Ex. på en lördag klockan 13.00 så är det ju 240:- som gäller, medans en vardag klockan 12.45 är det 120:-
Fråga 2:
Säg att en användare jobbar mellan 10.00 och 19.00 en lördag. Då ska han ju först ha 2 timmar med grundlönen och resterande tid med OB-lönen. Hur sjutton skriver man en fråga som räknar ut inkomsten under den tiden?
Hoppas någon förstår hur jag menar, för jag har ingen aning om hur man ska lösa det här.
Dela upp det i flera tabeller. Det är ju onödigt att spara arbetsplatsens id och användarid på varje dagalternativ. Vad skiljer förresten användarid och id åt?
workid eller userid beroende på om OB-gränserna skiljer sig åt mellan arbetsplatser eller individer.
factor - det som salary ska multipliceras med.
weekday SET('Mon','Tue','Wed','Thu','Fri','Sat','Sun')
starttime
endtime
Ditt exempel:
INSERT INTO tabellen VALUES (workid, 2, 'Mon,Tue,Wed,Thu,Fri', '19:00', '24:00');
INSERT INTO tabellen VALUES (workid, 2, 'Sat', '12:00:00', '24:00:00');
INSERT INTO tabellen VALUES (workid, 2, 'Sun', '00:00:00', '24:00:00');
Snowblade:
Mjo förvisso. Men om jag kodar in att OBlön = 2 * grundlön direkt i php-filen så är det ju väldigt statiskt (och det gäller för alla användare). Om jag lägger det i databasen så kan jag ju åtminstonde göra det unikt för varje användare. Om lönen ändras blir det problem, det får den inte göra ;)
Som det är just nu så får man vid löneändring (om man inte vill påverka alla tidigare löneutbetalningar (vilket man troligen inte vill)) lägga till den nya lönen som ett helt nytt arbete, dvs. ett nytt workid. Det känns ju inte sådär jävla bra egentligen, men som sagt. Hur ska jag bygga upp databasstrukturen?
Tydal:
id-kolumnen var bara ett unikt nummer för varje post i databasen (samma userid kunde ju förekomma flera gånger), dock så är kolumnen onödig och kan plockas bort som du gjort. Säg att jag kör på din db-struktur och vill plocka ut lönen för en användare på fredagar klockan 18.00 respektive 20.00 samma dag. Hur skulle en sådan fråga se ut? Eller måste jag dela upp det i flera steg kanske?
Tänk om en användare har dubbla arbeten? Hur blir det jobbigt om man inte har userid och workid för varje post. Hur ska man kunna skilja på när en användare jobbade var?
För att beräkna lönen för den tid personen jobbat skulle jag gjort så att jag tagit fram vad som gäller för en viss veckodag och sen använt php för att plocka ut det som är relevant: (exempelvis en tisdag)
SELECT starttime, endtime, factor FROM tabellen WHERE FIND_IN_SET('Tue', weekday) AND workid = nåt ORDER BY starttime;
Sen är det ju bara att använda lite if-satser för att ta reda på om någon del av arbetstiden ligger inom OB-perioden.
Förresten, när jag tänker efter, ha inte 2 som factor vid det här exemplet, utan ha 1. På så vis får du ut =tillägget= som OB utgör. Då kan du börja med att räkna ut personens lön för samtliga timmar som han/hon jobbat och sedan lägger du på OB efteråt för de timmar som omfattas.
Är det vanligt att en användare jobbar på flera ställen där det här systemet ska köras? Om det inte är vanligt skulle jag nog ha registrerat det som två användare, med två userID:n. Men kan ju ändå koppla ihop dem på personnummer.
> Går det inte att plocka ut "faktor-ob" och "koppla den till userid
> de tiderna som gäller.
Jag hade hoppats på att varje arbetsplats har samma OB-regler för samtliga anställda, så man bara behöver koppla OB-faktor till workID, och inte behöver ha det på varje anställd.
Mig veterligen kommer system aldrig att användas i skarpt läge, jag gör det bara för att lära mig. Det där med 2 användare på olika arbetsplatser lär ju därmed inte bli speciellt vanligt, men det vore intressant att se hur man bäst löser det utan att köra med dubbla användare (även om det kanske vore det allra smidigaste).
Bör man alltså ha 5 tabeller:
*en tabell med arbetsplatser och dess ob-faktor (är ob alltid i procent förresten? Eller finns det företag som kör med en viss pengasumma som OB oavsett grundlön??)
*En tabell med de arbetstider som gäller för OB-tillägg
*en tabell med användare och dess grundlön
*en tabell som knyter användare till företag
*en tabell med alla användares arbetstider
Känns som jag missade någon tabell, men kan inte komma på vilken just nu.
Nåja, man ska inte vara trött när man funderar på sådant här, så jag får nog sova på saken, men tack för hjälpen så länge iaf. Spåna gärna på med mer tankar och idéer. Alla tips tas tacksamt emot :)
