Модель данных для расписания для задачи и / или расписания для проекта?

Question

Допустим, я хочу создать простую систему отслеживания проектов. Менеджер может создать проект. Затем он может создавать задачи для этого проекта. Члены команды могут записывать часы, которые они работают для каждой задачи или для проекта в целом.

Является ли следующий дизайн таблицы 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. Тогда я смогу отслеживать все часы для проекта, который не предназначен для какой-либо конкретной задачи.

Какие-нибудь идеи выше хороши? Что было бы лучше?

Answer 1

Хотя я полагаю, что внешние ключи, имеющие значение NULL, имеют свое место в реляционных базах данных, в этом случае я бы предпочел ваш второй вариант.

1. Заставляет руководителя проекта явно создать "мицеллярный задача «элементы» для каждого проекта заставит их решить, имеет ли это смысл для рассматриваемого проекта или нет.

2. Позволяет менеджеру проекта вызывать задачу catch all как угодно.

3. Будет просто пользовательским интерфейсом, так как не нужно будет никаких особых случаев, чтобы назначать работу над проектом напрямую, а не задачей.

4. Упростит написание отчетов для разработчиков, поскольку им придется иметь дело с менее сложной моделью базы данных.