On Jan 27, 9:56 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> On Tue, 2009-01-27 at 09:57 -0800,AlmostGeorgewrote:
> > -- 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
Malcolm,
Thanks so much for your time and input. I thought I was "thinking
through" rather than pre-optimizing, but felt like I was leaving
something out (which was probably the indication of pre-opt')...
though I seemed to be drawing the same conclusions when "just doing
it" - so thanks for the prod in the correct direction. Tremendous
help. = )
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
