So let’s say that I have a database for managing customers. A customer has all the basic properties that one might expect — however, there are special kinds of customers called distributors. A distributor doesn’t have any special properties in and of itself, except that it can distribute products to certain markets which are stored in a market table.
I can think of two ways to go about distinguishing distributors from ‘regular’ customers:
-
Create a discriminatory column in the customer table called ‘customer_type’. This column would contain a value that would distinguish between ‘regular’ and ‘distributor’ customers.
-
The benefit of this approach is that it’s very simple, and new customer types can be added easily if needed.
-
The drawback of this approach is that my market table which links markets and ‘distributors’ would in this case would really just be linking markets to ‘customers’. There is no way to enforce that a market is linked to a customer of the distributor type.
-
-
Leave the customers table alone, and create a distributor table that basically just has an id column and a foreign key column to the customer table.
-
The benefit of this approach is that my market table can now link to the distributor table, which only contains distributors. There is no chance of linking to a customer that is not a distributor (as might occur if a customer ‘type’ were changed from distributor to regular).
-
The drawback of this approach is that it’s much more complicated, and adding new customer types is very difficult.
-
What else might I be missing, and what are your opinions on this matter?
I’d go with having a separate table for distributors with its own key/id. If all distributors are customers then it can foreign key into the customers table.
Eventually you may want to add properties to distributors. Then I’d have a separate table linking markets to distributors (which itself might change over time).
Often entities (e.g., distributors) that start out with only a few properties end up having a lot more.