views:

118

answers:

1

Let's say I want to make a simple project tracking system. A manager can create a project. Then he can create tasks for that project. Team members can record the hours they work for each task or for the project as a whole.

Is the following design for the t_timesheet table a good idea?

timesheet_id - primary key, autoincrement
project_id - not null, foreign key constraint to t_project
task_id - nullable, foreign key constraint to t_task
user_id - not null, foreign key constraint to t_user
hours - decimal

Or should I do something like this:

timesheet_id - primary key, autoincrement
task_id - not null, foreign key constraint to t_task
user_id - not null, foreign key constraint to t_user
hours - decimal

In the second option, I intend to always have a record in t_task labelled "miscellaneous items" with a foreign key to the relevant t_project record. Then I'll be able to track all hours for a project that aren't for any particular task.

Are any of the ideas above good? What would be better?

A: 

While I believe that nullable foreign keys do have their place in relational databases, in this case I would tend towards your second option.

  1. Forces the project manager to explicitly create a "micellaneous items" task per project will make them to decide if it makes sense for the project in question or not.

  2. Allows the project manager to call the catch all task whatever they want.

  3. Will simply the user interface as there won't need to be any special case to assign work against a project directly and not a task.

  4. Will make writing reports much easier for the developers as they will have to deal with a less complicated database model.

Bermo