Question

I’ll take a simplified StackOverflow system as an example.

Although limiting some features, it would be possibly to hold Questions and Answers in the same table:

(Django-esque pseudo-code)

QA table:
    parent = ForeignKey(self)
    category = ForeignKey(Category)
    title = CharField()
    description = TextField()

Then, to get the Questions and Answers for Question with ID 1, an SQL SELECT would be done for id==1 or parent==1. The downfall would be that the tags and title fields aren’t used by Answers

The alternative of course would be two tables:

Questions:
    category = ForeignKey(Category)
    title = CharField()
    description = TextField()

Answers:
    parent = ForeignKey(Questions)
    description = TextField()

Which would require two queries to get the Questions and Answers.

Instinct says the former is a horrible idea but I’m not sure why.

Which is faster and more scalable?

Answer 1

To answer your questions directly, your instinct is correct. Mixing entities (Questions and Answers) together into one table is almost always a bad idea. Logically they are 2 separate entities and physically they should be kept separate.

Your second solution is the correct one. Using indexes and foreign keys to link the 2 tables via the question id would allow you to select all the answers for any of the questions. This would be faster and would scale better in addition to being more understandable to anyone who had to work with the structure in the future.