Once more, I improved the model of my application. I wasn’t satisfied with the fact, that I was indeed able to store the time report data for each day of the month, but have an UI on a monthly basis and so one screen for multiple DailyReports.
Now I modelled it the way, that I have a (monthly) TimeReport which has many DailyReports. This way a DailyReport belongs to a Project and a (monthly) TimeReport. And a TimeReport belongs to a specific user/employee.
That’s exactly how I wanted it to be from the beginning. I don’t no why this took me this long…
Now it’s also no problem to get nice URLs for a TimeReport. For example like this: http://…/TimeReport/DanielPietzsch/2008/3/ for March 2008.
Hi. I'm Daniel Pietzsch and this is my innoQ-Blog. I'm a 26y old student at 
Comments (2)
In some special cases there might be a need for multiple entries per day for a TimeReport. According to this there might be a better name than DailyReport, although the relationship (TimeReport -> DailyReport) is sufficient, DailyReport.Date is not an suitable identifier.
Posted by Phillip Ghadir | 12.03.08 00:30
Posted on 12.03.08 00:30
Hi Phillip,
thanks for replying.
I was aware of the fact that DailyReport.Date is not a suitable identifier. I think I'll have an ID as a primary key or go for a combination of DailyReport.Date and the foreign key Project.ID as a primary key.
Ok, that was not clear when looking at the graphic...so it's my fault. I should have mentioned the primary keys as well.
Concerning the naming of DailyReport, I should really choose a name that is more representative.
Posted by Daniel | 12.03.08 12:34
Posted on 12.03.08 12:34