On Dec 5, 2007 6:09 AM, Richard Heyes <[EMAIL PROTECTED]> wrote: > > 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?
The storage concern comes if you opt to store one copy of the event for every day for as long as the event recurs. Why? Perhaps you want to provide the ability to alter the time of a specific instance of a recurring event (or delete one instance altogether) without changing the other instances. > > 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. > If you are only storing a single row for an recurring event rather than one row for each instance, then you have to evaluate your rule for each event inside the view you are displaying (month, year, etc.) to determine the dates for the event. I'm not talking grinding a server to a halt, but depending on how many events have to be calculated and how many users you have at a given moment, it could become noticable. > > 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 ** > Calendars themselves aren't that much to build. Even simple one-time events are pretty easy. Beyond that, all I'm saying is that you have to make a design decision based on your needs as to whether you store a lot to avoid repeating calculations or calculate more to store less. In any event, the biggest troublemaker I've had to deal with when it comes to calendars have been related to time zones and daylight saving time. Andrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
