Database architecture

Question

For example, I have posts, answers for post and comments for answers.

What better: to have each table for each entity (posts, answers, comments) or one table with 'post_type' and 'parent_id' parameter?

UPD: answers and comments are similar with properties.

Answer 1

The best route would be 3 tables:

• Posts
• Answers
  • Posts_ID (parent)
• Comments
  • Answers_ID (parent)

Posts being the ultimate parent, answers linked to it, and comments linked to answers.

Answer 2

Whether you have separate tables for posts and comments depends partly on whether one can be used instead of the other and partly on how similar is the processing on each. Put another way, how much information is unique to each? If there is nothing or almost nothing unique to each, then one table would very probably work.

Answer 3

Under certain circumstances it makes sense to use a single table with a differentiator column (option 2) BUT any columns that belong solely to one type should go into its own table, and that table will have a foreign key mapping back to the main table. This will form a table inheritance hierarchy .

This makes sense if the objects these tables represent share a significant number of columns; and their commonalities allows for some processing to be generalised across the different types without having to know the specific subtype.

If the majority of your queries end up having to filter by the differentiator column, what real advantage do you gain from storing them in the same place?

In short: KISS applies; if there is a programming advantage to be had by using the single table approach, use that; otherwise keep it simple and use 3 (counter intuitive I know, but the added cognitive load just to do self-joins all the time should convince you).