Two tables or One?

[Kaye Wykoff]

I designed and maintain a membership database for a
charitable org I belong to. Since I'm self taught and
have trouble linking tables, I just have one table with
all info (general membership info). I do pretty good
writing queries, reports, and designing forms, etc. We
have about 500 members and I can manage most everything,
but have a new situation that I need to address. There
is a second 'database' (in MS Works) from previous years
that contains about 2500 names and addresses for a 'non-
member invitation list'. We combine this with our
membership list to create a giant invitation list for our
annual fundraising event and other solicitations.
I have been eliminating duplicates and getting the large
list ready to import over to Access. Question: Should I
just add these to my membership table? Or create another
table?
If it is in a second table, can I write a query combining
the two for mailing labels sorted by zip code so bulk
mailing is a little easier? It would also help to have
the two combined so I can always make sure there are no
duplicates on the two lists. But I don't know if such a
large # in one table is a good thing to do? To keep the
non members from showing up in membership lists, there is
a Status field identifying types of memberships or non-
memberships.
Thanks for any advice you can give me.
KW

 

[John Vinson]

Question: Should I
just add these to my membership table? Or create another
table?

Either way can work. I'd lean a little bit toward using a single table
with (as you note below) a Status field

If it is in a second table, can I write a query combining
the two for mailing labels sorted by zip code so bulk
mailing is a little easier?

A UNION query will do the trick here. It's a bit obscure but it's
designed for just this purpose: to splice two tables of identical
structure end to end. See the online help for UNION or post back if
it's confusing.

It would also help to have
the two combined so I can always make sure there are no
duplicates on the two lists.

A UNION query by default discards duplicates. A cautionary note
though:

Jim Robert Smith, 339 W. Main St., Ashburg NC
James R. Smith, 339 West Main St, Ashburgh N.C.

are not duplicates in any of their fields, much less identical
records. Some manual processing will be essential.

But I don't know if such a
large # in one table is a good thing to do?

<chuckle> When you get over a million rows in your table, come back
and talk. Tables can be ten times that size.

 

[Kaye Wykoff]

Thank you, I'll study the info about Union queries & post
back if I need help with them. I know that my single
table needs to be split into several tables to be done
right. But I just can't get my brain around the
relational linking, etc. I understand the concept and
know what I need to put into different tables, i.e. Names
& addresses in one table with standing committees in
another and offices in another. But the linking escapes
me. Where would you suggest that I go to see examples or
get help with this? I've got books, but need something
more. Maybe I don't have the right books? Can you
suggest one? Thanks, KW

 

[John Vinson]

I understand the concept and
know what I need to put into different tables, i.e. Names
& addresses in one table with standing committees in
another and offices in another. But the linking escapes
me.

A many to many relationship (each person can be on several committees,
each committee has several members) is indeed one of the concepts that
you have to "click" to get. The way I like to think of it is that each
Table represents some real-life thing - a person, an organization, a
thing, an event; and the status of "being a member of the Welcoming
Committee" is a real-life thing! You need a third table,
CommitteeMembership, in which each record records the membership
status of a person on a committee. It would have fields for the
MemberID and the CommitteeID as links to those tables, along with any
other information about that membership status (e.g. DateFrom and
DateTo, officer status and the like).

Where would you suggest that I go to see examples or
get help with this? I've got books, but need something
more. Maybe I don't have the right books? Can you
suggest one?

The best I've seen is Rebecca Riordan's _Designing Relational Database
Applications_, alas now out of press. One book I don't have but which
I can strongly recommend, both by hearsay and by the excellence of the
author, is John Viescas' _SQL Queries For Mere Mortals_.