0

I guess this is a very basic question and must have similar issues, but the truth is that I have found very little information. I am developing a website with multiple types of content: articles, threads, recipes, etc.. All these content types can comment and do "like". Comments may also receive "likes". I am no specialist in database architecture, and how I developed the prototype was to establish different tables: comment_article, comment_thread, comment_recipe ... and like_article, like_thread, like_recipe, like_comment.

Now I want to simplify the structure of the minimum number of possible tables: comments and likes.

I would like to know the most performance efficient way to accomplish this:

  1. Field content_type, parent_id to specify the type of content and your referral id.
  2. Fields content_type, thread_id, article_id, recipe_id.
  3. Any others?

Note: We are using relational database with InnoDB storage engine.

StarsSky
  • 6,721
  • 6
  • 38
  • 63

2 Answers2

1

I'm not an expert on this, but no answers yet, so I will try to come up with an answer:

You'd only want different tables/columns if the content-types are very different from each other, i.e. that the fields need different types. If all are for example 'text', you just add a column 'type' in the , which you can later manipulate independently in your code.

Comments will be a seperate table with a relation(FK) to the Content(PK).

Likes too. This table will have have a reference (FK) column to content (PK) and a reference column (FK) to comments (PK), of which only one is set per like ofcourse.

matthijs
  • 489
  • 1
  • 8
  • 20
0

For those with a similar problem, a well explained answer can be found here: Implementing Comments and Likes in database

Community
  • 1
  • 1