Question

I’m looking for a best practice solution….

I have table that holds products called products, certain products have other products (options) that need to be associated with them so that when users view a product they also receive a list of all the other products (options) associated with it.

My first instinct was to create a simple reference table. While this works, you’ll see that there could potentially be a lot of redundant data.

**Ref table**
Product, product (option) to be associated

widget1, widget2
widget1, widget3
widget4, widget2 and so on...

My next attempt was to incorporate a key table.

**Products table**
product_id
key_id

**Key table**
key_id
product_id_fk

key_id would not be unique because a key should be able to reference more than one product(option).

This works a little better but it will still cause problems if all option sets are suppose to be unique. This method allows for only one set reference (group of options) to be associated with a product.

I believe one of the most efficient ways to solve this problem is to have all the unique sets of options created then reference each unique set to the product. Some help?

Answer 1

What is the “redundant data” concern with the reference table?

• Is the relationship between A & B always reciprocal? If we’re talking about products and options, I would tend not to think so (i.e. it probably makes sense if you’re selling a cell phone to provide a list of accessories as options, it probably doesn’t make sense if someone is looking at cell phone cases to suggest that they buy a new phone). If they are reciprocal, however, the widget2, widget1 row would be redundant because you already captured that relationship with the widget1, widget2 row.
• I assume when you are illustrating your reference table that you’re storing the product_id for widget1, widget2, and widget3 in both columns where you write “widget1” rather than storing the actual product name which is presumably much longer than the product_id