Reputation: 2112
I'm a database newbie designing a database. I'll use SO as an example because it's easier to ask it on something that you can see already, but it's not the same, it will just help me understand the right approach.
As you can see, there are many questions here and each can have many answers.
The database is both read and write if that makes any difference in this case.
Upvotes: 0
Views: 239
Reputation: 1573
You shouldn't worry too much about normalization and scaling initially -- just get the problem laid out in a clear way so you can try things out and see how it goes. The "standard" approach to a Q&A-type schema would be to have a table for questions, and a table for answers. Each answer belongs to one question, and therefore you'd have a question_id in the answers table which will point to its question. You could (and likely should) create an index on that column in the answers table to help optimize lookups. So for example you'd probably start with:
questions: question_id, question_text answers: answer_id, question_id, answer_text
And to get the answers for a question, you'd simple "select answer_text from answers where question_id=?".
Hope that helps as a starting point. There are different approaches if you start to approach truly huge numbers of entries, but as Marcelo mentioned above, 100k entries is really very small for a modern database.
Upvotes: 0
Reputation: 185852
Upvotes: 2
Reputation: 13798
Doing a google search brings up: http://sqlserverpedia.com/wiki/Understanding_the_StackOverflow_Database_Schema and https://blog.stackoverflow.com/2008/09/what-was-stack-overflow-built-with/
Upvotes: 1