1

I'm creating a webapp that has a variety of models: Product, Category, ProductOption, etc.

All of these models have a set of shared attributes: name, description, image, etc.

There are two options I see: 1. adding all of these attributes as columns to each of the model's table. 2. create a separate meta table that contains these columns with a polymorphic relationship between a model and the meta.

Option 1:

products
    id
    ...
    name
    description
    image
product_categories
    id
    ...
    name
    description
    image

Option 2:

products
    id
    ...
product_categories
    id
    ...
metas
    id
    name
    description
    image
    metaable_id // foreign key
    metaable_type // model type (Product, ProductCategory)

Is there a clear decision here? Am I missing any alternatives? Thanks.

  • 1
    I think it may depend on why are these columns common to multiple models? Are they independently / coincidentally similar, like a course product has a name and category has a name? Or is there some design element which makes them the same? Ordinarily, I would choose for option 1 because its just simpler, but 2 could be superior in cases where you have heavy design abstractions which require it. – Brandon Aug 5 '15 at 0:46
3

To me, there's no question. Go with Option 1.

It makes sense that you'll have Products and Categories. They're different, and shouldn't be forced to live in the same table. However, a productName (reasonably shortened to 'name') is not the same as a categoryName (also reasonably shortened to 'name'). You can use context to figure out which 'name' you mean.

Look at this another way:

Imagine it's now 5 years in the future. Your code is in production, is successful, and a team of people have been adding features to it. There are a lot of new models besides Product and Category. Let's say there are about 20 of them.

  1. Which option would be easiest for them to work with?
  2. Which option will be easiest for a new hire to follow?

Say you were away for those 5 years and are now getting back to this code.

  1. Which option will the team have messed up the least?
  2. Which option will you most easily follow?

(You can probably guess that I'd answer Option 1 for all of these questions)

I see where you're coming from with Option 2, but IMHO that looks like a giant plate of spaghetti code just waiting to happen. Even if you have the discipline to keep it clean, the programmer who comes after you may not.

I agree with Brandon that there may be some situation where Option 2 starts to look viable, but it would have to be much more esoteric than 'name', 'description', or 'image'.

  • Excellent. You reuse code because different things have something in common from a requirements standpoint and not just because two separate things happen to have a similar functionality. – JeffO Aug 5 '15 at 3:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.