in reply to Scheduling/dates design -- iCal + RMDBS? Or...?

As shmem points out storing iCal data in a database is a rather silly idea. iCal is a data exchange format, and is not a sensible way to store dispatch data if you want to be able to rapidly perform calculations as all you can get the database engine to do is cough up data which you must then parse into a useful internal format for manipulation. You can not avoid the fact you need this internal representation for you calculations so just store it, preferably in a well indexed way that lets you get maximum mileage out of the DB engine.

In terms of development I would suggest putting aside all your ideas about generalizing it well and open sourcing it (noble as they may be) and look at an "agile software development" model and write some simple code that actually does something rather than some complex code that might do everything for everyone.....eventually.

You may save yourself a lot of time by looking into rostering software

cheers

tachyon

  • Comment on Re: Scheduling/dates design -- iCal + RMDBS? Or...?

Replies are listed 'Best First'.
Re^2: Scheduling/dates design -- iCal + RMDBS? Or...?
by Your Mother (Archbishop) on Nov 24, 2007 at 20:37 UTC

    Good advice, thanks. Ironically, it's how I already solved a few other parts. My first schema was much bigger and clumsier than after I took a higher view -- divorcing myself entirely of the initial target case -- to abstract the elements and write a bunch of story cards for the application. I think I dropped about five tables and several redundant, or ass-backwards foreign keys. I'm writing failing tests right now based on the story cards. Really trying to follow best XP for a change and see how the experience differs from some past projects. :)

    Last night I realized I had abstracted things apart correctly except for frequency. A single "job" shouldn't own/know its frequency but that's where I had the data living. Moving it out simplifies everything; and allows for smooth higher abstractions if API guts change b/c of shoddy, I mean sub-optimal, early choices.