February 10, 2011 at 7:12 am
hey all,
I'm developing some tables for a new application, and part of it has a list of tasks that must be performed, however, there are strict rules on when some tasks can run and some can't. I have a group of tasks for different conditions and there are some precedence requirements which differ from task group to task group.
So for example.
taskgroup1 has to run the following tasks: task1, task2, task3, task4, task5 and task6.
task 1 MUST be run first, nothing can run before it
task 2 can be run at any time
task 3 MUST run before task 4 and before task 6
task 4 MUST run after task 3 and before task 6
task 5 MUST be run after task 2
task 6 MUST be the last task to run.
These could be completely dynamic, based on what I put in my tables - but I'm going round and round on the best way how..
I considered a header table with my conditions, then a group table, then a detail table, like so.
taskgroupheader: conditions + identifier
taskgroup: identifier and order by sequence, also include a flag to run 'anytime'
taskgroupdetail: each task, a sequence and the group identifier
I figured this way I could put task 1 in a group on its own, task 2 in a group on its own, task 3 and 4 in a group, task 5 in a group and task 6 in a group, and then try and use the group sequence numbers to drive which order things run in..
My question is - is there a simple, better design here I'm missing?
--------------------------
I long for a job where my databases dont have any pesky users accessing them 🙂
February 13, 2011 at 9:51 am
Wouldn't it just be easier to make two "control" stored procs? One to run task 2 followed by task 5 and another to run the others in the proper order.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply