Quote:
Originally Posted by Derision
I'm still undecided about how to implement the predecessor activity requirements. E.g. say a task has 10 activities and when you completed activity 1, activities 2 and 3 open up. Task 4 then won't open up until tasks 2 and 3 are complete.
As I see it, I can either put a limit on how many predecessors an activity can have (let's say 4), and then have four columns in the table, predecessor1, predecessor2, etc.
Or, have a text field which could contain a comma separated list of predecessors, e.g. "2,3". I dislike this because it means I have to parse the string to get at the predecessor info.
I'm leaning toward option 1 (a fixed, small number of predecessors and having a column for each).
Still lots left to do!
|
I think something like the "_entries" or "_metadata" tables currently in the database would work best, similar to what KLS recommended above. Here's an example:
Code:
CREATE TABLE TaskOrder (
taskid int(11) unsigned NOT NULL,
activityid int(11) unsgined NOT NULL,
step int(11) unsigned NOT NULL,
PRIMARY KEY(taskid, activityid)
)
"step" could be used to group each stage, so using your example, activity 1 would be step 1, activities 2 & 3 would be step 2, and activity 4 would be step 3:
Code:
taskid activityid step
1 1 1
1 2 2
1 3 2
1 4 3
That way, it's more dynamic, and doesn't create a large table if you want something more than 4 prerequisites deep.
Hope this gives you some ideas, the whole task system seems REAL promising
