Yeah, I'd actually considered that. We do use that method on another product.
The big upside is that you don't have to store exceptions if you remove just one date in the future from the recurrence pattern, you just remove that one date record from the database. There can be a big downside depending on what you are using it for. I'm using this sort of model for a "Resource Availability" kind of thing. Bookings/reservations etc. can be made against the available resource occurrences. If you want to change the schedule, you have to delete, re-insert or at least update all the actual records in the database, possibly all of these. If you have bookings against the original pattern then what to do with those existing bookings becomes a problem. You also have to consider storage. Several 10 of millions of explicitly stored dates might become a problem :) Basically the problem needs to be thought through from beginning to end. Not only how you are going to query the records, but also how you might update them together with any (possible) dependent records. Bottom line options: Store minimal data (rules) and dynamically regenerate actual dates on query. or Store actual absolute dates (possibly with the original generation rule) and work out how to update them. Storage and efficient query as opposed to raw cpu power perhaps? It's not always easy..... Regards, Gary. Jeremy Dunck wrote: > On 3/8/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > ... >> Also I store these Schedules as a top level table. I then create >> Resources (Events?) that "use" a specific schedule. This way I can >> have lots of Resources that use the same Schedule, again minimising >> the number of schedule records. > > It seems we all have this problem. :) > > I was thinking about doing something similar to what Gary's doing, but > I'm more concerned with fast access than minimal records. Also, > there's a "reasonable" window of time for which we'll ever have > records, say 10 years. > > As such, I was thinking about having an Event model with recurrence > rules (perhaps admin'd with a little DSL), then blowing out a lot of > EventTime records for all the occurrences. Editing would always be to > Events; EventTimes would be regenerated upon Event save. > > The reduces queries to a simple date range, allowing very efficient index > usage. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
