On Tue, 2009-01-27 at 09:57 -0800, Almost George wrote: > -- MODELS -- ( Other, unimportant fields/models have been removed ) > > class Band(models.Model): > name = models.CharField(max_length = 50, unique = True) > > class Venue(models.Model): > name = models.CharField(max_length = 50) > > class Event(models.Model): > name = models.CharField(max_length = 50, unique = True) > info = models.TextField(max_length = 200, blank = True) > date = models.DateTimeField() > bands = models.ManyToManyField(Band) > venue = models.ForeignKey(Venue) > > If an Event is part of a Tour/Festival that has multiple dates (not > necessarily consecutive) I don't want to re-enter the bands and extra > info for each Event - where, essentially, I'll only have a different > Venue and Date assigned. > > Currently, the Automatic Admin gives me the ability to quickly add/ > change Bands and Venues for an Event, in one place. I'd like to keep > it that way if possible. > > I've been thinking this into the ground on the best way to abstract > the Bands/Dates/Venues from the Event without causing rediculous > amounts of Joins to happen just to list the Events by date, and show > which Bands will be at each.
You won't be able to create "ridiculous" amounts of joins. Databases are optimised to handle joins (certainly dozens at a time and often more), so stop trying to prematurely optimise. There's simply no other way to view what you're doing. Even with really huge and complicated schemas "normalise until it hurts; denormalise until it works" is the right order. You aren't approaching that order of complexity, so you can focus on step one for now. It sounds like an event should have a many-to-many relation to a date-range class that specifies the various dates. That will allow searches for events on a particular dates, dates for a particular event and so on. You should be able to organise things so that Festivals are simply Events. In fact, it seems to be that the whole structure here sort of rotates around Events. Without events, you have nothing, whether the event is a garage band gig or Woodstock. So I'd drive outwards from there. Events have multiple dates associated with them (as above -- I'd use a dateinterval style of class, but that's optional). They also have a many-to-many relation to bands, which is the band or bands that are part of the event. You might want to do that via a manual intermediate model (ManyToManyField(through=...) ) if the bands for an event also carry extra information (headliners, first support act, etc). And a Festival (name adjusted to choice) that is OneToOne with Event -- from Festival -> Event, since every Festival is an Event, but not vice-versa -- which provides extra information about the festival. There are possibly other structures, but that's one that comes to my mind after a little thought. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
