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 Tues Wed Thur Fri Sat
>> Grill steaks 8 8 8 8 0
>> Vacation 0 0 0 0 8
>> So why wouldn't I store the dates and the hours instead of start and
>> stop times?
> Maybe it comes down to what the users of the app prefer (or what you prefer,
> you're building this app for yourself).
> From a user's perspective, I like start/stop data-entry better. I love that I
> can do this in Freshbooks, for example -- just click 'start' and then later
> click 'stop', 'log hours' -- and I never have to think about things like "how
> many hours are there between 11:26am and 2:12pm"?
> I think Ralph's point was that start/stop data is about as granular as any
> of time-keeping data gets, so if you store only start/stop data, you have
> ultimate flexibility in the way you can manipulate that data in your app.
> And it's probably a reasonable generalization that the most forward-looking
> database designs will store data in as simple and raw a form as possible. Or
> Ralph put it, "a good data design keeps only data in a table u can not
> With start/stop data, you could create weekly timesheets like the one above,
> PHP -- and you could also figure out how many hours you log before noon, on
> average, etc.
> On the other hand, if the simplest data you enter is already the implicit
> result of a calculation (stop_time - start_time), you've limited the
> flexibility of your app from the get-go. But maybe that limitation isn't
> significant for the app you're building.
I see. I'm coming at this from an IT consultant perspective, where
you're just like an employee, you work M-F 8 or so hours a day normally.
So really your just filling it out for billing but it would normally be
8 hours M-F sometimes with vacation etc.
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php