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