Need help with Event Registration

Databases
1

I’m trying to create a more sophisticated back-end to manage Events Registration, and need some help.

Here is how I’m thinking of laying things out…

RELATIONSHIPS:
One SHOW has zero or more EVENTS

One VENUE has one or more EVENTS

One VENUE has one or more ROOMS

One ROOM has zero or more EVENTS

An “Event” is the thing I’m really trying to model, and here is a made-up example…

[INDENT]“Elvis Impersonators Competition” (Show)
Ramada Inn (Venue)
12575 River Road
Minneapolis, MN
Saturday, Oct 22, 2011 (Date/Time)
1:00-4:00pm
Main Banquet Room (Room)[/INDENT]

As I see it, an EVENT is made up of a SHOW (e.g. “Elvis Impersonators Competition”) + VENUE (e.g. “Ramada Inn, 12575 River Road, Minneapolis, MN”) + DATE/TIME (e.g. “Saturday, Oct 22, 2011 at 1:00-4:00pm”) + ROOM (e.g. “Main Banquet Room”).

QUESTIONS:

1.) How does that look?

2.) If VENUE maps to EVENT and VENUE also maps to ROOM which maps back to EVENT, is that okay? (Seems kinda circular?!)

3.) Do I need DATE/TIME + ROOM?

Technically, I could use just one or the other…

I just need a way to be more specific than a particular DATE and VENUE, because an EVENT could be held multiple times in the same day and it could be in different ROOMS too.

What do you think?

In the end, I am just trying to build something that is accurate and that scales well.

Sincerely,

Debbie

2
  1. fine
  2. it’s transitive, not circular, and it’s okay
  3. only if you want to know where and when an event is being held

:slight_smile:

3

[/quote]

Okay.

[/quote]

Well, the Events Planner would need to know an Event’s Date/Time and Room, of course. However, what I was trying to imply was “How should I set up the Primary Key”?

For the EVENT table, the Primary Key could be a composite that looks like either…

1.) ShowID + VenueID + DateTime + Room

2.) ShowID + VenueID + DateTime

3.) ShowID + VenueID + Room

As I see it, #1 would be the most explicit and give you coverage if you had two of the same Events at the same Venue and Date/Time. (Although this is unlikely, since I believe most of these Events have a Speaker/Personality/Entertainer and that is just one person.)

It seems like #2 and #3 are the same as far as coverage…

To your point r937, of course I would have a field for all of these attributes, but what makes the most sense for the PK?

Also how would choosing one versus the other affect performance and just general database creation and management?

Sincerely,

Debbie

4

the one that uniquely identifies an event

choosing a PK is not about performance, it’s about identity and uniqueness

5

So, given these 3 choices, which one would make the most sense…

1.) ShowID + VenueID + DateTime + Room

2.) ShowID + VenueID + DateTime

3.) ShowID + VenueID + Room

If the same Event is held simultaneously at the same Date/Time, then you would need #1.

However, since there is almost always only one Speaker/Performer/Entertainer, then I think either #2 or #3 will work.

Maybe #2 is more flexible if the Room changes at the last moment?! :-/

I could use a little more help here… :wink:

Thanks,

Debbie

6

1.) ShowID + VenueID + DateTime + Room

this works

2.) ShowID + VenueID + DateTime

this means a show can take place multiple times at the same venue, but only ever in one room (or no room at all)

3.) ShowID + VenueID + Room

this means that a given show can occur in multiple rooms at the same venue, but it can only ever have one datetime (which means it has to take place in those multiple rooms simultaneously, but only once)

7

As far as I know, since there is only one Entertainer/Performer/Speaker at any given Event, then it sounds like #2 is the best way to go.

That way “The Joe Polka Show” can play multiple times at the same Venue on the same Date, but at different Times and then each one is treated as a unique “Event”.

Thanks for the help, r937!!

Debbie

P.S. I have some more questions on setting up my tables for this.

Should I start a new thread, or continue here, even though they don’t relate to this discussion - except for linking to EVENT…