naming question - non programmatic question [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts开发者_运维知识库, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 11 years ago.

I have two tables in my db: Customers and Subcontractors.

Now it appears that some customers can be also subcontractors.

What I decided to do is to create a base table (super type) that holds the common data and then complete the relevant info for each type (customer, subcontractor) in other table. It will be something like this:

 NEW_TABLE<------Customers
          <------Subcontractors

The problem is that I don't really know what to call this table. Is the name "Partner" the best option?

---

Agreed with the other responders. More information about the domain is needed before getting really useful answers.

But I'd suggest ThirdParty or ExternalParty, since I'm assuming Customers and Subcontractors are external to your business. Internal parties could be User, InternalParty, etc.

I think you've tagged this question properly.

Hope this helps.

---

Nobody can answer your question without knowing the domain. It can be partner, contact, company.

---

'Party' may be a good name. You can find this and this interesting. Or just google "Database Party Model".

---

IMHO, there are two main options:

1. Have a single table called third_party that has a party_type column of either 'customer' or 'subcontractor' (and others and time goes by, like 'supplier' etc). The details are largely contact details, which are common to all third parties
2. Have two tables like you have now, but store the common data in a separate table, for example contact_details, and have a foreign key from both tables to that details record. When a customer is also a contractor, both records would point to the same details record.

I prefer option 2, because it allows different relationships to exist for each type.

---

I'd call it SubcontractorBase, but as Peri points out it is hard to say without knowing the domain

---

What about having a single table, with all of the options (however named) as BOOLs so that you could easily indicate when a party belongs in more than one group (you'd also be able to add categories as needed in the future)