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.
In reply to Re^2: Scheduling/dates design -- iCal + RMDBS? Or...?
by Your Mother
in thread Scheduling/dates design -- iCal + RMDBS? Or...?
by Your Mother
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |