Re: Calendar

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Dec 5, 2007 6:09 AM, Richard Heyes <richardh@xxxxxxxxxxx> 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


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux