Best practice for parent child relation

This is a bit late, but the previous answers don't provide the third alternative which is both flexible and normalized.

All tasks should be kept in a Task table, because subtasks after all are just tasks.

The relationship between tasks should be stored in a second table that has columns to identify the parent/sub task relationship based on a foreign-key relationship with the Tasks table, and which together would form a composite primary key.

Tasks

• id

• title

• description

• start_date

• end_date

TaskRelationships

• parent_task_id

• sub_task_id

In order to find the parent tasks of a given task you can query the sub_task_id column. To find the sub-tasks of a given task search the parent_task_id column.

This structure has the added benefit of having the flexibility to add as many parent tasks to a task as your wish.

It depends.

If your model is fixed as that which you state in the example data, and always will be, then the first way will work and will enforce that model.

If you might later want, or already want to support, a deeper model (i.e. splitting sub-tasks into smaller units of work) then you need the more generic tree structure permitted by the second option. This disadvantage of this is that while you have the single level model is that you need to make sure that you enforce it as the general parent/child relationship will allow data that is not valid in that model.