There is not much "simple" about a calendar, especially when you start dealing with recurring events. How far into the future your calendar allow events to recur will depend at least in part on how you intend to store them. For instance, you can store them in a database where you create a separate event row for each occurrence (though still be linked by a common ID as you said), but you'll probably set your limits based on storage to prevent adding a daily event for the next 10 years.
Stipulating an event to be daily could be as simple as a 0 or 1 flag. So where's the storage concern?
> You could also store a single event record that includes the
rules for recurrence and then calculate the dates of each instance as needed, but that could get pretty CPU intensive. (I'm assuming you want to stick with "simple" periodic recursion, not more complex things like the date for Easter or events that don't have any set pattern.)
I really don't see anything CPU intensive about this. At most you're going to be storing some set dates that the event should occur on. Nothing CPU intensive about that.
I know this probably muddies your original question even further, but I'll say again -- there is not much "simple" when it comes to calendars.
Calendars can be simple, or they can account for a lot and be complex. -- Richard Heyes http://www.websupportsolutions.co.uk Knowledge Base and HelpDesk software that can cut the cost of online support ** NOW OFFERING FREE ACCOUNTS TO CHARITIES AND NON-PROFITS ** -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
