RE: Merge (sort of) 2 databases into one
- From: PS <PS@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 5 May 2009 19:44:02 -0700
Karl,
That was a little more than 1.5 pennies. Thanks. I think I am following
you. The client, enduser and contacts are exactly as you have stated,
although I've got the contacts in a separate table and displayed as a subform
in the "Data Entry" form.
The Contracts have a lot of very specific details about the equipment,
process, fabrication and cost and I've broken them out into these separate
tables - but again, it all seems to be one-to-one - revolving around the
common contract number.
If I build a table with the Relations as you suggest aren't I then adding
redundant data, or am I just not getting what you're trying to tell me?
I have to look at my tables again. I had thought I had a pretty good
structure and all I had to do was focus bringing it all together.
The junction tables as you describe them sound like a viable solution and I
will take a look in that direction.
Thanks so much for helping me out.
-PS
"KARL DEWEY" wrote:
Here is a penny and half..
It seems to me that Clients, our client's clients (which we refer to as
EndUsers) and their respective Contacts are just three groups of people that
all have the same data - name, address, phone, fax, cell, etc. So it seems
to me the they can all go into one table, just omitting any data one might
not have such as text address. So, one table, each with an unique ID.
Next maybe build a table that has a list of Relations - Contract, Client,
EndUser, Contact, etc.
Another table listing Contracts or Systems, StartDate, EndDate, etc.
They all have either an up or down or both relationship to others. Use a
Junction table - Enity_1, Enity_2, Relation (Client - EndUser), Active
(DateTime), Ended (DateTime), Contracts , etc.
Set up one-to-many relationships between the related tables.
Enity - Junction
Relations - Junction
Contracts - Junction
etc -- Junction
Use form/subform for each one-side/many-side (Joe to Moe, Benny, & Homer)
with a combo to select many-side folks.
There will be several of the one-side/many-side displays.
"Fred" wrote:
Hopefully someone else will answer on this also, here's a few thoughts.
It looks like you are setting up a pretty cool and complex CRM/Contract
management system. Hopefully someone responder can tackle this.....I have
a feeling that it would take a few posts to get/understand the important
information. And then a transition from an old work done by someone else
makes it even more fun/complicated than designing it from scratch.
I'd suggest starting by thinking about what table structure you want to end
up with, and use that as your "lighthouse" to work everything else towards.
Figure out what the main "entities" are that you are databasing, and what
type of relationships there are between them. Start by answering these
questions in "outside world" terms and THEN in table/relationship terms.
Only about 30% of your post was even on this topic, and even that 30% kind of
hopped around rather than making the core statements. Post this info if you
need help to design a good table structure.
There's my 2 cents, hopefully others will have stuff to say.
- References:
- Merge (sort of) 2 databases into one
- From: PS
- RE: Merge (sort of) 2 databases into one
- From: Fred
- RE: Merge (sort of) 2 databases into one
- From: KARL DEWEY
- Merge (sort of) 2 databases into one
- Prev by Date: RE: Merge (sort of) 2 databases into one
- Next by Date: Re: Beginner - Stevie still thinks he is an ASSet
- Previous by thread: RE: Merge (sort of) 2 databases into one
- Next by thread: RE: Merge (sort of) 2 databases into one
- Index(es):
Relevant Pages
|
