> 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 calculate". 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. Ben -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
