Suppose I have a blog post entity.
- It has many attributes
- It has comments attached to it.
- It has many states (deleted/locked/invisible, etc).
- It has many “tags”. (keywords, school_id, user_id)
Obviously, comments should be its own table, with a many-to-one relationship to Blog table.
But what about “states” or “tags”? Would you put that in another table? Or would you stick that in many columns?
What about attributes…if they get too big? Because as my website grows, the blog post will have more and more attributes attached (title, author, blah, blah….). What happens if the attribute list goes as high as 100?
first of all, states should be a tightly structured thing, so you should create separate columns for them. Think about what you need at the beginning, but you can easily add one or two more columns later.
Tags like keywords shouldn’t be stored in columns, because the amount is growing rapidly over time. That wouldn’t make any sense. So for that, build a table with id and keyword in it and a link table with post_id and keyword_id. You could also omit the keyword_id and directly link post_id and keyword.
Make sure that both columns combined define the primary key, so you can not end up with a keyword stored several time to one particular post.
For attributes it can be the same. It is not a bad practice to create an attribute table with attribute_id, attribute_name and maybe more information and a link table attribute_id and post_id and content.
You can also easily enhance it to be multilingual by using attribute_ids.
Comments are the same, stored in a separate table with a link to a user and a post: comment_id, user_id, post_id, content and maybe parent_id, which can be a comment_id if you want comments to be commentable again.
That’s it for a brief overview.