Re: What's the best way to set this up?
From: John Vinson (jvinson_at_STOP_SPAM.WysardOfInfo.com)
Date: 03/13/04
- Next message: Allen Browne: "Re: Simple relationship question"
- Previous message: Joe Fallon: "Re: Numeric vs. Text IDs"
- In reply to: Susanna: "What's the best way to set this up?"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 12 Mar 2004 22:29:26 -0700
On Fri, 12 Mar 2004 17:01:08 -0800, "Susanna"
<anonymous@discussions.microsoft.com> wrote:
>Here's the problem. Currently, there are a bunch of
>different tables within a single database, one for
>artists, one for curators, one for mailing list, etc.
<g> Yep. Very common. I've been paid to fix worse...
>But this means that when a new entry needs to be entered,
>it must usually be entered in five different places.
Indeed.
>What I want to know is whether there is some way to set it
>up so I can enter the information once into the form, and
>then simply say, "put this into the artists table, the
>curator table, AND the mailing list table." and it will.
VERY good thought!
Here's how I did a very similar (church membership, with many lists)
database:
- a table of People. Any person in the system - artist, donor, whoever
- getss put into the People table. (Well, in my case it was a Family
table with addresses linked to a People table, but that's probably an
unneeded complication for you). If you have organizations on the
mailing list just treat them as a type of "person" - they'll still
have a name and address.
- A table of Lists - in your case, containing records like "Artists",
"Donors", "Curators", "Mailing List", etc.
- A third table, Membership: each record in this table has a PersonID
linking to People, and a ListID linking to Lists.
This lets you put any person on any desired number of lists; any list
can have any number of people; people's data gets entered once only
and needs to be edited only in one place. You can very easily generate
a mailing-label report by joining the three tables, and putting a
criterion of (say) "Artists" on the list-name field.
>And if there is then presumably some way to edit the
>information and find it, so that if a mailing list person
>suddenly decides to become a member, I could go and just
>find their name in the mailing list, and say "put all this
>person's information into the membership table, too."
Just add a record for that person the Membership table. No need to
"put all that person's information" anywhere that it isn't already!
>Another issue is that the computers are all networked, so
>one person could have the artists table open, and another
>could be doing a mail merge with the mailing list open,
>but they couldn't both have the artists open at the same
>time.
Access is inherently multiuser. Provided that the two users aren't
actually *EDITING* the content of the same record at the same time,
there should be very little conflict.
>That means that storing all the information in one table
>(which would cumbersomly have to have separate columns to
>determine what functions the person had, volunteer, donor,
>artist, etc.) is not an option, because everyone in the
>office is constantly having to have various tables open,
>and needs to be able to access (no pun intended) the
>information all at once, or as close as possible to all at
>once.
The scheme above does this very smoothly.
If you'ld like a copy of the church membership database as a model
drop me an EMail at jvinson <at> wysardofinfo <dot> com and I'll send
you a copy.
John W. Vinson[MVP]
Come for live chats every Tuesday and Thursday
http://go.compuserve.com/msdevapps?loc=us&access=public
- Next message: Allen Browne: "Re: Simple relationship question"
- Previous message: Joe Fallon: "Re: Numeric vs. Text IDs"
- In reply to: Susanna: "What's the best way to set this up?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
