Naming relational tables without getting ridiculous

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 开发者_C百科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

---

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.