任务时间表和/或项目时间表的数据模型？
假设我想制作一个简单的项目跟踪系统。经理可以创建项目。然后他可以为该项目创建任务。团队成员可以记录他们为每项任务或整个项目工作的时间。
t_timesheet 表的以下设计是一个好主意吗？
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
或者我应该这样做：
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
在第二个选项中，我打算在 t_task 中始终有一条标记为“杂项”的记录，并带有相关 t_project 记录的外键。然后，我将能够跟踪不用于任何特定任务的项目的所有时间。
上面的想法都不错吗？什么会更好？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
虽然我相信可为空的外键确实在关系数据库中占有一席之地，但在这种情况下，我倾向于第二种选择。
迫使项目经理
明确地创建“胶束
每个项目的“项目”任务将使他们决定这对相关项目是否有意义。
允许项目经理根据需要调用捕获所有任务。
将简单地显示用户界面，因为不需要任何特殊情况来直接针对项目而不是任务分配工作。
将使开发人员编写报告变得更加容易，因为他们将不得不处理不太复杂的数据库模型。
While I believe that nullable foreign keys do have their place in relational databases, in this case I would tend towards your second option.
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.
Allows the project manager to call the catch all task whatever they want.
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.
Will make writing reports much easier for the developers as they will have to deal with a less complicated database model.