Thread: Cenceptual help needed - periodic events

I'm goofing around, designing a planned maintenance system. In a couple of
weeks I'll be taking on the actual scheduling of tasks. How would you
experts out there approach this? I've beeen thinking I can approach this two
ways.

1) When a list of tasks is requested, generate new rows and store them.

2) When a list of tasks is requested, look at the task row and calculate the
tasks, display them, but do not generate rows for storage. Just calc on the
fly all the time.

Method #1 would mean less CPU and RAM use but then I'd have to worry about
tasks changing or being added to a maintenance schedule and not being
reflected in any pre-generated rows. #2 would alleviate that problem, but
may be slower overall and perhaps eat large amounts of ram.

If anyone has done something similar with periodic events, what did you find
worked best?

I'm planning on using a base task record to record the frequency and other
specifics of a task. This record is the basis for generating the periodic
tasks.

One row:
task_id =1 (serial)
task_system = 1
task_equip =  12
task_text = Lubricate fan shafts with lithium grease
task_interval = 1 month (using an interval type column)
task_startmonth = 2 (offset so that not ALL 6 month interval tasks actuall
happen in June)

Another row:
task_id =25 (serial)
task_system = 8
task_equip =  72
task_text =
task_interval = 6 month (using an interval type column)
task_startmonth=3

Then I'll have to step through the calendar by month and match up all the
task rows and print out a single page for each system.

This is all a brand new concept to me, so any suggestions are more than
welcome. I still have a few weeks work in other areas to keep me busy, but
this is the toughy that I'm spending brain time on =)

Pat,

> I'm goofing around, designing a planned maintenance system. In a
> couple of
> weeks I'll be taking on the actual scheduling of tasks. How would you
> experts out there approach this? I've beeen thinking I can approach
> this two
> ways.

I'm working on a legal calendar system, and we're storing all events as
rows in the database.  However, in our case the reasons are
overwhelming, since the rules on how new events are generated (aside
from those entered by users) are complex enough to fill several pages.
Calculating on the fly isn't conceivable.

Also, all of our events are, at one level or another, dependant on a
user-entered event.  Thus we can make all auto-generated events
"children" of the parent event and change them when the parent changes.

I designed another system that was all auto-scheduling -- a weekly
produce delivery system.  In this system, we took the expedient of not
generating any even more than a week ahead of time, and providing
functions that would drop all events and then re-create them,

Differently, in a time entry system I designed all of the due dates for
timecards were calculated on the fly by a complex view. 

So it depends on the number and complexity of the rules you will be
applying.  If the rules are very complex and/or require procedural
logic, you probably want to generate and store records.  Otherwise, no.

-Josh

______AGLIO DATABASE SOLUTIONS___________________________                                      Josh Berkus Complete
informationtechnology      josh@agliodbs.com  and data management solutions       (415) 565-7293 for law firms, small
businesses       fax 621-2533   and non-profit organizations.      San Francisco