trying to figure out the best database schema

I want to come up with a generic schema (if possible) to use for a number of different events that I am managing. These events can be weddings, birthday parties, etc.

So far I have 3 main tables:

1. Contact Table - the usual info like address, phone, etc.
2. Events Table - a list of events with some info like date, location, etc.
3. EventInfo Table - contains the following fields (not complete but you should get the point):

EventID

ContactID

NumberofAdultsInvited

NumberofChildrenInvited

Responded (yes, no)

NumberofAdultsAttending

NumberofChildrenAttending

This is the table that I'm trying to improve. I am trying to figure out the best way to capture the event data where we want to keep track of data across adults and children.

It seems strange that I need these repetitive fields for adults and children, but I can't think of any other way. I don't want to put NumberAdults and NumberofChildren in the contact table because number of children doesn't necessarily equal numberofChildreninvited (sometimes adults are just invited)

Do you have any ideas how I can clean up this schema or is the above the best that I can get?

NOTE: In the contact table, there is one entry for the family (as it has one address) so there are not fields开发者_开发问答 stored per person within a family.

Here's how I'd model the database based on the provided info:

EVENTS

• EVENT_ID
• ADDRESS_ID

INVITATIONS

• CONTACT_ID
• EVENT_ID
• RESPONDED

CONTACTS

• CONTACT_ID

It's not a good idea to model a contact to be encompassing an entire family. It makes it easier to invite & track things if a contact represents a person rather than a household. After all, a household can have anywhere from 0 to ~18 kids, and may not include a significant other. Each person, assuming teens & up, will have unique contact info (IE: cell phone(s), work numbers, email, etc). This also makes it easier to determine headcount...

The invitations table allows you to summarize invitations & confirmations:

  SELECT e.event_name,
         SUM(invited.contact_id) 'total_invited',
         SUM(confirmed.contact_id) 'total_invitations_confirmed'
    FROM EVENT e
    JOIN INVITATIONS invited ON invited.event_id = e.event_id
    JOIN INVITATIONS confirmed ON confirmed.event_id = e.event_id
                            AND confirmed.responded = 'Y'
GROUP BY e.event_id, e.event_name

Just need to join to CONTACTS table to determine age and then be able to subcategorize the invitations between adults & children.

FAMILIAL_RELATIONS

• CONTACT_ID
• RELATED_CONTACT_ID
• RELATION_TYPE (parent, child, aunt/uncle, cousin, blacksheep etc)

Use this table to rollup to get household members...

CONTACT_METHODS

• CONTACT_ID
• METHOD_TYPE (phone, cell, biz phone, fax, email, IM, etc)
• METHOD_VALUE

CONTACT_ADDRESS_XREF

• CONTACT_ID
• ADDRESS_ID
• ADDRESS_TYPE (home, business, etc)

ADDRESSES

• ADDRESS_ID
• ADDRESS_1
• ADDRESS_2
• ADDRESS_3
• ADDRESS_4
• CITY
• PROV_STATE
• POSTAL_CODE
• COUNTRY

You'll notice I made a one to one relationship with EVENTS and ADDRESSES, while supporting one-to-many contact to addresses. Locations will be relatively static, compared to people. This format would allow you to easily check which event locations are popular, so you could use the information to get better rates in the future.

Regarding addresses for the same household: That's why the ADDRESSES is a separate table - you don't need to retype it for each person, just associate to the correct address record.

Do you need to track the indiviual invitations and responses?

If so you could have a separate table for Invitations and their statuses. Then you could obtain your counts from queries against that table.

If you are simply keeping a track of counts I might normalise to separate tables for InvitationCount with a discriminator column for Adult, Child or anything else. This avoids hard coding into your schema just two categories of invitation. Perhpas in the future you might have more categories (eg. Customers, Clients, Participants, Observers, Performers, Musicians, Donors, Honorary members ...)

[T]he contact right now is the whole family as one invitation is sent to one family

In that case, and absent any other requirements, I'd probably suggest a similar route to what you've already proposed.

The redundant fields aren't an issue, since they are tracking a unique fact about the Invitation, not the contact.

I'd probably keep a separate table for the Response (with number attending, which may be different from number invited) or an Attendee table, but it's not really necessary given your current requirements.