Ben Dunlap wrote:
>> OK, I think I understand most points except the start and stop time.
>> Every time sheet I have used, SAP and several other smaller ones, I
>> enter a weeks worth of time data like:
>>
>> Project Sun Mon TuesWed ThurFri Sat
>> --
Ralph Deffke wrote:
> as I said, the job is to store a time sheet.
> u came up with:
>
> 1. One record for each 7 day week (year, week_num, d1, d2, d3, d4, d5,
> d6, d7) where the dX field holds the hours worked
> 2. One record for each day (date, hours)
>
> it seems that just the first record is
as I said, the job is to store a time sheet.
u came up with:
1. One record for each 7 day week (year, week_num, d1, d2, d3, d4, d5,
d6, d7) where the dX field holds the hours worked
2. One record for each day (date, hours)
it seems that just the first record is fine. in a data design u dont hold
> OK, I think I understand most points except the start and stop time.
> Every time sheet I have used, SAP and several other smaller ones, I
> enter a weeks worth of time data like:
>
> Project Sun Mon TuesWed ThurFri Sat
>
Ben Dunlap wrote:
>> sorry man, but a good data design keeps only data in a table u can not
>> calculate. in ur case that would be only and time.
>> refernces to user and project/tasks in other tables.
>>
>> ur time sheet is definately a job for a report. that type of design limits u
>> to nothi
off course, but this is a different subject, means a finished, not changing
time sheet is to store. in that case I would prefere to use a single record
for each sheet holding an id, possibly a date and then a medium text holding
a simple xml notation of the sheet. the benetit of that concept is aga
> sorry man, but a good data design keeps only data in a table u can not
> calculate. in ur case that would be only and time.
> refernces to user and project/tasks in other tables.
>
> ur time sheet is definately a job for a report. that type of design limits u
> to nothing. a user can start an
sorry man, but a good data design keeps only data in a table u can not
calculate. in ur case that would be only and time.
refernces to user and project/tasks in other tables.
ur time sheet is definately a job for a report. that type of design limits u
to nothing. a user can start ans stop as ma
On Wed, 05 Aug 2009 22:18:31 +0300, Shawn McKenzie
wrote:
So, obviously not PHP related, but I'm looking for thoughts on the best
way to record time sheets in a DB. A time sheet for hours worked per
day, not like a time clock where you start and stop.
The two possibilities that I have thoug
9 matches
Mail list logo
