2 数据库设计问题。 层次树

Question

1.) I have a DB where each entry represents a task. And out of several dozens or even a hundred of task, there will be a special task (which is a milestone)
So, in this case, I have very few entries that requires an extra field to separate them from the majority.

I don't want to create a second table, because this is the only fields that makes these milestone stone special, they share a lot of other fields with regular tasks entries.

Should I create another field just to hold a few TRUEs while the rest are FALSE by defaul

2.) For each of those tasks, it has a variable number of performers (depending on user input) (To further things, each performer has multiple sub-performers of its own.) So I essentially am using a DB to describe a TREE structure.The way I have it now is, I will have 5 copies of the same task info if there are 5 performers, and occupy 5 entries. Is this the way to go if I'm not going to have more than 10,000 entries (incl. copies) in my DB

Thank you

This should clarify it

1. Task1 (this is a milestone task)

   • performer1
     • sub-performer ID=21
     • sub-performer ID=542
   • performer2

2. Task2 (this is not a milestone task)

   • performer2
     • sub-performer ID=231

Subperformer and performer are completely different group. No overlap at all. Subperformer are the group that provide inputs to performer, so performer can complete the task they're assigned to.

Answer 1

I am not sure if this is what you want:

tblTask with columns taskID, isMilestone, and everything you need.

tblAgent with columns agentID and everything you need (these will be the (sub-)performers).

tblPerformance with columns fk_agentID, fk_task

tblSubperformance with columns fk_agentID_performer, fk_agentID_subperformer

Being fk_ foreign keys referencing

fk_agent -> tblAgent.agentID
fk_task -> tblTask.taskID
fk_agentID_performer -> tblAgent.agentID
fk_agentID_subperformer -> tblAgent.agentID

Answer 2

1) yes create a boolean flag.

2) no. if you have duplicate data you have a problem. you need to normalize

Answer 3

You're really not exploiting the relational nature of databases. The nice way to do it is:

• Have a table of tasks (with unique ids, without the extra milestone field, without the preformers)
• Have a table of milestones with two columns: the task id and the special milestone field -- only milestones will appear in this table
• Have a table with two columns: task id and performer

• Have a table with two columns: performer and sub-performer

• If a performer can have multiple fields, use a prerformer id in the tables above and have a table with performer id and other fields

Re: Comment

I have read that normalization can reduce DB efficiency, that's why I combine them all.

Where? It's a pretty strange claim.

For the table that contain taskid and performer (the 3rd on your list) Would it be like, if task 143 needs Staff A, B, C. In DB, (row 1| 143 | A) (row 2| 143 | B) (row 3| 143 | C) Don't you still have redundancy?

The repetition in the third table isn't a redundancy problem because you aren't replicating any information: the information in the table is about relationships and there are three relationships in three rows.

A redundancy problem appears when you have a setup like yours, were, let's say task 143 has a completion_date "May 31, 2011" then your table would look like:

task_id  completion_date  performer
143      May 31, 2011     A
143      May 31, 2011     B
143      May 31, 2011     C

Now let's say I want to change the completion-date for task 143. In your setup I have to change it in all three rows, and what's worse, if someone does something wrong you could get an inconsistent table like:

task_id  completion_date  performer
143      May 31, 2011     A
143      May 12, 2011     B
143      May 31, 2101     C

And now you don't know which is the right completion_date , When you normalize, you only have one row in one table to change the date. and your database is never inconsistent like that.