S
Shabam
I'm having a calendar feature developed whereby users can add recurring
events. These recurring events can have start and end dates, meaning they
will recur only within a date range. For instance, user A creates an event
that recurs every Tuesday, from 1/1/05 - 3/2/06.
The developer has decided that it would be good to have another table that
stores each individual recurring event in a separate record. His logic is
that this will help with the display of calendar months. His logic is, if
the application has to dynamically iterate through every event record in the
database and logically map out which days have recurrence, that it would not
be good for performance.
My take though, is that if one recurring event can literally add in 10,000
records, then that's even worse.
What are your thoughts on the proper way to implement this?
events. These recurring events can have start and end dates, meaning they
will recur only within a date range. For instance, user A creates an event
that recurs every Tuesday, from 1/1/05 - 3/2/06.
The developer has decided that it would be good to have another table that
stores each individual recurring event in a separate record. His logic is
that this will help with the display of calendar months. His logic is, if
the application has to dynamically iterate through every event record in the
database and logically map out which days have recurrence, that it would not
be good for performance.
My take though, is that if one recurring event can literally add in 10,000
records, then that's even worse.
What are your thoughts on the proper way to implement this?