[thelist] SQL: database/table design

[Joshua Olson]

> -----Original Message-----
> From: Colin Gremillion
> Sent: Friday, June 04, 2004 10:14 PM
>
> Anyway, my manager hated this idea, and suggested that
> I make a new table, where each event-speaker
> relationship would have a record. So I now have this
> table with three fields: "SpeakerID" (linked to
> "speakers"), "EventID" (linked to "seminar") and
> "SpeakerType" which says if they're "primary" or
> "secondary".

Colin,

This is probably one of the best ways to do this.  The only gripe I would
have is that you reference the PK to the seminar table as "EventID"... I
think I'd personally opt for "SeminarID", but that's just me.  Also, make
sure you "SpeakerType" field is not a string field... make it a numeric,
such as tinyint, and use a number to represent the type (1 = primary, 2 =
secondary, for example).

> I've got the statement working, but it's a nested
> inner join and I hate doing those. Is there a better
> way to do this? Keep in mind that events and speakers
> are always mutually exclusive.

What does "mutually exclusive" mean in this case?  It most likely doesn't
affect this best solution, but I'm curious nonetheless.

Good luck,

<><><><><><><><><><>
Joshua Olson
Web Application Engineer
WAE Tech Inc.
http://www.waetech.com/service_areas/
706.210.0168