>> On a related note, what is the best way to make sure the same person
>> doesn't register more than once. I have it set so that the id number is
>> the primary key, should I make a field like e-mail unique and not
>> necesarilly primary?
>
>You could do that, or alternatively put a unique constraint on the
>combination of the two columns glastname, gfirstname.

Even (first name, last name, alumniID) is unlikely to be unique in
the guest table. What happens when an alumni invites Mr. & Mrs.
Quetzel Katzenheimerrr as two of his guests? And in any size class,
it's likely more than one person will invite a John Smith.

Email addresses may be a problem because related people (and people
married to each other) may share the same email address (also maybe
address and phone number). Also be prepared to have Mr. & Mrs.
Henry Brown register as different alumni, which may well NOT be a
mistake, and they might have the same email, address, and phone
number.

I think it is more important to NOT refuse legitimate registrations
than to refuse duplicates. In the case of the guests, the alumni
are filling out the form, right? Show them a complete list of their
guests (4 max) and ask them if they want to add, delete, or change.
That will make duplicate GUESTs for the same alumni unlikely, and
hard to do accidentally. I don't think two different alumni inviting
the same guest will be that much of a problem (possible exception:
the two alumni are married to each other but don't communicate well.
They want to invite more than 4 people so they have to split up the
list between them).

>Any way you do it, there will be ways for people to sign up more than
>once. Maybe someone uses their yahoo.com email the first time, but a
>gmail.com address the second time. Or else they spell their name Bob
>once, but Robert the second time. It's practically impossible to
>prevent all such cases, so you need to include in the system some way
>for a user to un-subscribe, or if you want to be really fancy, provide a
>way for them to merge their two subscriptions into one (for instance, if
>one has their correct contact details, but the other has the correct
>guest list).

It is probably more important to be able to correct duplicates
(when detected manually) than to reject them when they occur. And,
as above, there are plenty of ways duplicate-rejection can fail to
reject real duplicates. But having the system reject NON-duplicates
is even more embarassing, especially when you can't fix it.

Gordon L. Burditt