Question

Consider a database with tables Products and Employees. There is a new requirement to model current product managers, being the sole employee responsible for a product, noting that some products are simple or mature enough to require no product manager. That is, each product can have zero or one product manager.

Approach 1: alter table Product to add a new NULLable column product_manager_employee_ID so that a product with no product manager is modelled by the NULL value.

Approach 2: create a new table ProductManagers with non-NULLable columns product_ID and employee_ID, with a unique constraint on product_ID, so that a product with no product manager is modelled by the absence of a row in this table.

There are other approaches but these are the two I seem to encounter most often.

Assuming these are both legitimate design choices (as I’m inclined to believe) and merely represent differing styles, do they have names? I prefer approach 2 and find it hard to convey the difference in style to someone who prefers approach 1 without employing an actual example (as I have done here!) I’d would be nice if I could say, “I’m prefer the inclination-towards-6NF (or whatever) style myself.”

Assuming one of these approaches is in fact an anti-pattern (as I merely suspect may be the case for approach 1 by modelling a relationship between two entities as an attribute of one of those entities) does this anti-pattern have a name?

Answer 1

Well the first is nothing more than a one-to-many relationship (one employee to many products). This is sometimes referred to as a O:M relationship (zero to many) because it’s optional (not every product has a product manager). Also not every employee is a product manager so its optional on the other side too.

The second is a join table, usually used for a many-to-many relationship. But since one side is only one-to-one (each product is only in the table once) it’s really just a convoluted one-to-many relationship.

Personally I prefer the first one but neither is wrong (or bad).

The second would be used for two reasons that come to mind.

1. You envision the possibility that a product will have more than one manager; or
2. You want to track the history of who the product manager is for a product. You do this with, say a current_flag column set to ‘Y’ (or similar) where only one at a time can be current. This is actually a pretty common pattern in database-centric applications.