[AccessD] Many to Many relationship issue

jack drawbridge jackandpat.d at gmail.com
Sat Apr 12 13:20:30 CDT 2014


Jon,
Can you list the facts related to your database and the business processes?
Just to clarify the "things" you are dealing with and how they relate to
each other within the business.
I realize you have said
"... I work for a contractor and have a need to maintain a
customer table (contractor general information), a table for the contact
people at the contractor's companies, a projects table (jobs we bid) and a
table to log phone calls.  I have the tables created with an "associate"
table for the M2M relationship between the customer table and the jobs
table, another "associate" table between the customer contact table and the
phone calls table.  I also have a one to many created between the customer
table and customer contact table..."

What info do you have to maintain for historic or legal or other purposes?
Do you do regular reporting or analysis? If so, could you describe this?

As the others have said, I think the key is to get your database structure
design so that it meets your business needs.

Good luck.


On Sat, Apr 12, 2014 at 1:36 PM, Jon Albright <jon.albright at hawaii.rr.com>wrote:

> I appreciate your input Bill and I'm sorry if you misinterpreted what I was
> saying as a slam at the content you posted, I am only trying to understand
> how all the parts and pieces fit together and it was recommended that this
> forum is a good place for exchanging ideas and problem solving.
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bill Benson
> Sent: Saturday, April 12, 2014 7:07 AM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Many to Many relationship issue
>
> Maybe I used flatter incorrectly,  and maybe you use dependencies in a
> different context than I do.
>
> But I guarantee, GUARANTEE you that to keep an accurate audit and history
> of
> all the dependencies needed to populate what happened, when, on which jobs,
> for which companies, involving whom and in what roles... and be able to
> trace those deta I ls from the call table back to their components in the
> entity tables YOU COULD NOT DO IT while at the same time creating future
> transactions with fresh, current details. A call table is a history table,
> not an active environment. The active environment changes, the
> history/audit/warehousing details likely will NOT.
>
> Trying to preserve relationships kills, kills, kills reporting veracity
>
> If you want to improve "the quality" of the thread, get to it (but I don't
> like your implication that what has been offered so far is of low quality,
> that's rather rude).
>
> I am answering from my experience, yours is a welcome voice.
>
> I do not have any relationship diagrams to offer you.
> On Apr 12, 2014 12:38 PM, "Arthur Fuller" <fuller.artful at gmail.com> wrote:
>
> > Bill, et. al. on this thread,
> >
> > I seriously take issue with your comment that "the flatter your
> > information is, the less outside dependencies..."
> >
> > In my opinion, this is wrong, wrong, wrong. Or to phrase it another
> > way, this is the reason for Views, as opposed to direct table Selects.
> >
> > But this whole thread makes me wonder, Is there a way that we can
> > create a relational diagram, whether in Access or SSMS or some similar
> > tool, and include the diagram in the original post or its replies? For
> > this sort of discussion, a picture is worth 1000 words.
> >
> > Can this be done? I've not yet tried to do this; hence the question.
> > But I think that if it can be done, this would go a long way to
> > improving the quality of the threads.
> >
> > Arthur
> >
> >
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>


More information about the AccessD mailing list