So it dawned on me last week that I need to start thinking about the “back-end” of my Events Registration project. And it seems more involved than I thought, so I’d appreciate some help modeling things.
Here is what I have in my notebook so far…
Entities:
- Customer (person who buys things)
- Order (what a customer places)
- Ticket (allows people to attend event)
- Event (the actual date and location)
- Topic (the general theme for the event)
- Venue (where things happen)
- Room (specific location at venue)
Relationships:
-
One CUSTOMER creates one or more ORDERs
-
One ORDER has one or more TICKETs
-
One TOPIC has zero or more EVENTs
-
One VENUE has one or more EVENTs
-
One VENUE has one or more ROOMs
One EVENT has zero or more TICKETs
What do you think?
The area where I feel shaky is the relation between ORDER and EVENT…
Both from a database standpoint and a business standpoint, I’m uncertain how to handle Tickets and Attendees.
I had a good conversation with an SAP person at work, and he said, “It is hard enough to get the person placing the order to give out their name and personal information. Good luck trying to get other people attending an event to give you their info, let alone register?!”
Originally I wanted every person attending an Event to register and at least create an account with Name, E-mail and Password, but that seems like a “pipe-dream” at this point!!
I guess lots of events have generic tickets (e.g. movie theaters), but I am guessing that at a lot of Events, the organizer will want to know people’s names in case there is an issue with ticketing or at the event. For instance, if Bob buys 5 tickets for his friends for the Polka Dance, and his buddy Fred shows up but lost his ticket, then you have this whole issue of not being able to validate that his friend paid for him to get in?!
Anyways, how do the Tables that I have modeled so far look? How could I improve things?
Sincerely,
Debbie