Question

I’m working on a proprietary feedback application. I have a table named topics that I will to use to store suggestions, questions, and problems.

topics [ id, user_id, title, content, type[suggestion, question, problem] ]

I can easily store this data in one table using a type column to distinguish between the three different topic types.

However, there’s another wrinkle: Each topic has its own responses too, and responses are very similar to the topics themselves. I’m tempted to store them in the same table as well. So now I have type (suggestion, question, problem) and subtype (topic, response).

Am I asking too much of my topics table? Should I split my data into separate tables? I’m using Postgres and Rails for this particular project.

Best way to visualise is to compare it to StackoverFlow. SO stores questions and answers in the same posts table. Now suppose instead of only questions SO decided to allow suggestions and problems. Would they still use the same table?

Answer 1

How often you’ll want to query both topics and responses in one action? Maybe when searching, but sometimes you also want to search only topics or only responses. And how often you will need to query only one of them? Most of the time.

Go for two separate tables, you can use views with UNION clause if you want to use them together. Also at the application level you can build inheritance model on top of relational database. Say Post object with Topic and Response subclasses. Some libraries like hibernate will transparently translate query for *all posts that…` into two separate queries and union results together.

Another approach (also being one of the ways to deal with inheritance in relational store) would be to have… three tables! Posts, Topics and Response, the last two having foreign key to Posts. This way common columns are in one table and type-specific columns are separately.