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.
So you could have a table which contains events, and a table which
contains exceptions. Simple and minimal storage requirements. Since
exceptions will be, as their name suggests, exceptional, storage
requirements will be small.
--
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
