Best way to capture this information...

[kb178]

I'm not sure what the best way to handle some information I need to capture, so I thought I'd post it to tek-tips and see what you guys think...

It's for a database where attendees will be registered. A person will call and register multiple people. Those people need to be grouped together. Typically, I would go by the person calling (person calling is not a registrant) and put their unique identifier on each attendee. However, that person calling could have multiple groups of people they are registering and one person in each group needs to be identified as the leader of the group. An example of 1 caller could be:
Caller 1 calls:
Caller's Group 1 is:
Registrant 1 - leader
Registrant 2
Registrant 3
Caller's Group 2 is;
Registrant 1
Registrant 2 - leader
Registrant 3

What are the best fields to create to link all this information together?

Thanks!
Kristen

 

[johnherman]

Here's one (and certainly not the only) solution:


PersonTable
PersonID
PersonName

RegistrantTable
RegistrantID (foreign key to PersonTable)
RegistrantGroup
RegistrantLeaderFlag
RegistrantCallerID (foreign key to PersonTable)

-------------------------
The trouble with doing something right the first time is that noboby appreciates how difficult it was.
- Steven Wright

 

[willir]

tblRegistration
RegistrationNum - primary key
RegisteringPerson - name of person placing registration
... plus other details on registration

tblRegParty
RegPartyID - primary key
RegistrationNum
LastName
FirstName
... plus other people who are registered

Provide the person placing the registration the RegistrationNum.

A one-to-many registration exists for the registration and the parties / people registered. The person placing the registration is captured in case the registred party does not know their registration number. Then, one can query for the person who placed the registration, and then find the registered party in the records retrieved.

Richard

 

[alvechurchdata]

I'd add a third entity for Groups to give us flexibility for later. Someone's bound to ask us to store the date that a group was registered or the name of the staff member who handled it or the invoice number for this booking.

I'm also assuming that a person can be both a caller and a registrant:

Person
PersonPK && Primary key
Name && Name, address, phone, etc
Caller && Am I a caller?

Registrant
RegistrantPK && Primary key
GroupFK && What group am I in?
PersonFK && Who registered me?

Group
GroupPK && Primary key
PersonFK && Who is the leader of this group?

Identifying the leader is an interesting decision:

Do we store it in Registrant and add code to prevent there being one and only one leader per group?

Do we store it in Group and add code to ensure that the person identified is indeed in this group?

The only way to decide is to make a start doing it both ways and see which comes out easier.

Geoff Franklin

http://www.alvechurchdata.co.uk