Shared Entity in one to many database relationship

I have a database I'm working on the des开发者_运维知识库ign for. I have manufacturers and I have distributors on separate tables containing practically the same information with few exceptions. Both groups have one-many contacts that need to be connected to them. I created a contact table to hold contact information, one!

Do I need a second contact table? I'm trying to make this as DRY as possible. How would that look? Thank you in advance

---

Maybe a case for the party-role pattern? Manufacturer and Distributor are roles played by Parties. Contacts apply to Parties, not the role(s) they play. So you'd have:

• a table named Party
• a table named ContactMethod (or similar)
• a 1:M relationship from Party to ContactMethod

which would resolve the need for two Contact tables. How you model the roles side will depend on wider requirements. The canonical model would have:

• a single supertype named Role
• a M:M relationship from Party to Role
• a subtype of Role for each specific role (Distributor and Manufacturer in your case).

(Note: as an aside, this also allows a Party to play both manufacturer and distributor roles - which may or may not be relevant).

There are 3 'standard' patterns for implementing a subtype hierarchy in relational tables:

1. table for entire hierarchy
2. table per leaf subtype
3. table per type

(1) would apply if you don't have any role-specific relationships. (However I suspect that's unlikely; there's probably information related to Distributors that doesn't apply to Manufacturers and vice-versa).
(2) means multiple relationships from Party (i.e. one to each role subtype).

(3) avoids both above but means an extra join in navigating from Party to its role(s).

Like I say, choice depends on wider reqs.

hth.