> 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, if
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 sort
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 as
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, in
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.


PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to