Ask A Question

Notifications

You’re not receiving notifications from this thread.

Should Categories be it's own resource or model attribute?

Ariff Munshi asked in Databases
Hey guys, 

I have a question on database design. Say I have a Post model that has/belongs to a category (out of about 20 categories or so). I am thinking of two options that have their own merits.

1. Category as own resource with Post belong_to it
- this allows listing of all categories and posts under a category easy
- however, entries will most probably be done once at the start and then left to be

hence the other option

2. Categories as an attribute of Post
- scoping Post by categories is trivial still
- categories can be picked from a constant list

Would love to hear any of your comments on this how would you go about doing it.

Cheers!

Reply
Hey Chris, just wondering, have you designed the categories here in the forums to be its own Category model or a column list?
Reply
I setup my category as a model.  
Reply

Old post I know but it's quite a general question so will add my thoughts.

My decision making has always come down to whether there will only ever be one category, or potential multiple categories. For the singular, you can probably just add a column in your model, but for multiple entries, you might want to create a seperate category model, and then reference the two via a joins table.

This approach is very common for tags for example, but to be honest, I've started using it in many areas that can have multiple entries. e.g. flavours in coffee or different gin brands served by a bar.

At the end of the day, it's all just a type of tagging.

Reply

Hey Simon,

Thanks for your answer! Never actually thought of it that way. Come to think of it, it makes the most sense. Cheers!

Reply
Join the discussion
Create an account Log in

Want to stay up-to-date with Ruby on Rails?

Join 82,329+ developers who get early access to new tutorials, screencasts, articles, and more.

    We care about the protection of your data. Read our Privacy Policy.