Question

I am trying to implement a multiple choice quiz and will want to store all my questions and answers in a SQLite database. I will have many questions, and for each question there will 2 or more possible answers to display.

My question is, how should I store the questions and answers in a database? I have two ideas for a schema (primary key in bold)

1. as (many to many)

questions (questionID:int , questionString:String, correctAnswerID:int)

answers (answerID:int , answerString:String)

questions_and_answers (questionID, answerID)

2.

questions (questionID:int, questionString:String, correctAnswerID:int)

answers (answerID:int, answerString:String, questionID:int foreign key)

I’m not sure which one is better, or if there is another way?

Maybe questions_and_answers would get very large and cause long retrieval times and memory problems? Then again, I assume question_and_answers would be indexed on the primary keys. In the second schema, answers would be indexed on answerID and not questionID? meaning the search times would go up as the whole table would have to be searched?

There may be ~10,000 – 20,000 answers. (the quiz may be run on a mobile device and questions will need to be shown “instantly”)

Note: I don’t expect there to much overlap of answers between questions. I wouldn’t think the amount of overlap would mean less data being stored, considering the extra space required by the questions_and_answers table

Answer 1

You’re second schema is the better one, because it models the actual domain: each question has a set of answers. Even if you can “compress” the data by storing duplicate answers once, it does not match the actual domain.

Down the road you’ll want to edit answers. With schema 1, that means first searching if that answer already exists. If it does exist, you then would have to check if any questions still rely on the old answer. If it did not exist, you would still have to check if any other questions relied on that answer, and then either edit that answer in place or create a new answer.

Schema 1 just makes life really hard.

To answer your index questions, you would need to add an index on questionId. Once you have that index, looking up answers for a question should scale.

Now, on a completely different note, why use a database for this? Consider storing them as simple documents in a standard format like json. Anytime you query a question, you will almost always want the answers, and vice versa. Instead of executing multiple queries, you can load the entire document in one step.

If you then find you need more advanced storage (queries, redundancy, etc) you can move to a document database like MongoDB or CouchDB.