Question

I have a hierarchical data structure which, as far as I can see, needs to have a series of successive many-to-many relationships.

It goes something like this:

Company
Account
Treaty
Benefit
Policy
Person

With the following relationships:

Company 1---8 Account
Account 1---8 Treaty

…all still fun

And then, many to many:
Treaty 8---8 Benefit, so I create the relational table TreatyBenefit, and do:

Treaty 1---8 TreatyBenefit 8---1 Benefit

Now, for a specific Treaty and a specific Benefit (i.e. a TreatyBenefit) there can be many Policies. But again, a single policy can also fall under multiple TreatyBenefits

So, then I have TreatyBenefit 1---8 TreatyBenefitPolicy 8---1 Policy

And then of course, the same applies to Person, so I also then get:

TreatyBenefitPolicy 1---8 TreatyBenefitPolicyPerson 8---1 Person

What I would like to know is if there are any conventions for naming tables so that you can avoid names that become so long that they are essentially meaningless? Or are there better approaches to the design that avoids this kind of structure entirely?

Thanks
Karl

Answer 1

IMHO unless there are other strong, wideley accepted, meaningful business-centric names for these entities / concepts, then I would stick with the trusted Many:Many mangles that you’ve described above.

Also, each of the 6 entities you’ve listed are reasonably concise, so there seems little point in abbreviating e.g. Ben, Per, Pol, Acc, Co etc would cause more confusion than benefit.