Archief - SQL: Timesheet bewaren

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

El Pietrovich

Legacy Member
Hellow,

Als onderdeel van een site wil ik iets ontwikkelen waarbij gebruikers een timesheet kunnen invullen (gewerkte uren per dag ingevuld per week).
Nu ben ik een beetje de pedalen kwijt geraakt met te zoeken naar een waterdichte methode om deze timesheets in een database op te slaan.
Het moet namelijk eenvoudig zijn om het te bewaren in de database, maar ook eenvoudig om de gegevens terug op het scherm te toveren per week.

Waar het dus op gebaseert is, is een kalender.
Op een kalender selecteer je een week waarvan je de gepresteerde uren wil invullen.
Ik dacht het op deze manier op te slaan:

Tabel: Timesheets

Jaar Maand Week Ma Di Woe Do Vr Za Zo
2004 3 12 8 8 8 8 8 0 0
...

Waarbij
Maand 1 -> 12
Week 1 -> 52

Op deze manier zou het wel goed werken om op te slaan (denk ik).
Maar het probleem zit zich in de maandwissels, een week begint niet altijd op een maandag.
Om uit te lezen zou dit nogal problemen geven.
Het moet namelijk kunnen om bv de gegevens van week 23 (of whatever) op te vragen.
Indien deze week nu juist op een maandwissel valt en de 31ste woensdag is in die week. Dan moet ook nog een deel van week 24 getoond worden (DO, VR, ZA, ZO) om een volledige week op het scherm te kunnen toveren, en dan wordt het wel echt heel ingewikkeld.

Iemand suggesties / ervaringen?

Bedankt op voorhand!
;)

zero2one

Legacy Member
beter 1 tabel met volgende kollommen:

id (int)
user_id (int) verwijst naar een apparte tabel met users
datum (date)
prestaties (float 5,2)
eventueel nog een kolom dat er verlof opgenomen is, overuren, ....

op deze manier kunt ge gelijk welke dag/week/maand oproepen en eventuele totalen uitrekenen via een query, het datum veld en de date/time functions kan u al veel verder brengen dan uw voorgesteld systeem

paar voorbeeldjes:

alle prestaties van de maand september in 2004
SELECT prestaties FROM timesheet WHERE user_id=32 && MONTH(datum)=9 && YEAR(datum)=2004

totaal gepresteerde uren van de maand september in 2004
SELECT SUM(prestaties) FROM timesheet WHERE user_id=32 && MONTH(datum)=9 && YEAR(datum)=2004

voor de opbouw van een kalender zal je een query moeten combineren met de nodige code in php...

El Pietrovich

Legacy Member
Merci Zero2One.

Dus gij zou voor iedere dag een aparte record maken?
Wordt dat op den duur ni teveel?
Das max 31 per maand, per gebruiker.
Dus laat ons stellen dat de gegevens na 3 maand naar een archief database gaan.
Da is 3 x 31 = 93 records per gebruiker.
En het zal ongeveer gebruikt worden door een 25-tal personen, da maakt dus 2325 records om precies te zijn. Gaat ne query uitvoeren nog performant zijn dan? (maar een vraag hé, geen offense, want ik heb er geen idee van).

voor de opbouw van een kalender zal je een query moeten combineren met de nodige code in php...
Ik had hierbij gedacht om een asp.net kalender te gebruiken.

P.s: Voor de rest is deze oplossing inderdaad beter

zero2one

Legacy Member
kwa performantie kan een tabel met een goede indexering geen probleem vormen ( ik werk hier dagelijks met mysql tabellen met 4miljoen records en zware join query's zonder performantieprobs op een MySQL DB)

Als ik van u was zou ik geen weekend dagen wegschrijven in db tenzij er overuren gepresteerd zijn he ;)
meestal voor nen timesheet gebruiken ze volgende velden (uren steeds decimaal dwz een kwartier is 0.25 uur) :
gepresteerd normaal
overuren tarief 1
overuren tarief 2 (ge weet wel vanaf 10h is dat normaal meer)
verlof (aantal uren)
recup (aantal uren)
ziekte (geen uren)
...

als ge dat goed wil doen moet ge dat nog verder gaan normaliseren maar ik denk dat we in uw geval dan te ver gaan (ik maak uit uw berichtjes op dat ge nog niet zo ver staat met database toepassingen van deze aard?)

El Pietrovich

Legacy Member
Ah ok, zo zal het dan gebeuren!

als ge dat goed wil doen moet ge dat nog verder gaan normaliseren maar ik denk dat we in uw geval dan te ver gaan (ik maak uit uw berichtjes op dat ge nog niet zo ver staat met database toepassingen van deze aard?)
Nee inderdaad, het was vooralsnog bij veel pseudo probleempjes gebleven die genormaliseerd moesten worden, geen echt praktische zaken.

U weze bedankt!

edit:typo
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan