On Wed, 12 Sep 2007 10:56:17 -0400 Echo <[EMAIL PROTECTED]> wrote: > > On 9/12/07, Tim Riley <[EMAIL PROTECTED]> wrote: > > > > I'm rather new to the whole database modeling side of python and was > > hoping to get some thoughts from the experts on best practice. I'd > > rather go about this the right way from the beginning than monkey > > around with it myself and come to realize down the road that it > > won't work for me. > > > > In my spare time I'm trying to create a local entertainment site for > > the area in which I live. There is a lot of great stuff going on > > around here but it's really tough to find information about it. So I > > basically will have a listing of restaurants, bars, local events, > > etc. > > > > Now bars and restaurants will have some common attributes, hours of > > operation, daily special, etc. And all three could have events. So > > my question is do I create tables for each attribute needed or do I > > create common tables and use them across all three? For example: > > > > bar_table: > > nameField > > descField > > addressField > > etc. > > > > bar_events: > > nameField > > locationField > > whenField > > etc. > > > > restaurant_table: > > nameField > > descField > > addressField > > etc. > > > > restaurant_events: > > nameField > > locationField > > whenField > > etc. > > > > or do I use common tables > > > > bar_table: > > nameField > > descField > > addressField > > etc. > > > > restaurant_table: > > nameField > > descField > > addressField > > etc. > > > > events_table: > > nameField > > locationField > > whenField > > etc. > > > > I personally would do neither. > Here is something that I would do: > > locations_table: > location_id > type (something like 1=bar, 2=restaurant, 3=fastfood, etc) > name > description > address > etc > > event_table: > event_id > location_id (a foreign key) > description > when > etc > > -- > -Echo
I agree with the consolidation, but, "magic numbers" are generally frowned upon. In [locations_table] maybe the 'type' field could be 'type_id' and be a foreign key to another table: actually define the magic numbers. This will also allow finer control over the type of establishment. e.g. pub, disco, cafe, outdoor seating -or- geographic neighborhood -or- small venue, large venue.. etc. One may also consider that a place may be two or more 'types'. Obviously this depends on the application specs; but lookup-descriptors could be helpful. The type of event intersects with the type of the venue on a date at an address. -- michael --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
