STI Design Questions

It's often hard to keep up with changes in RoR, especially when you're still learning. A lot information on the web is for older versions of RoR. So I want to make sure this design using single-table inheritance (STI) makes sense.

My design need is identical to this: I have a Quiz class, a Quiz has_many Answers. Answers belong to a Student and a Question and Answers can be types such as TrueFalse (a bool), MultipleChoice (a string), Essay (a text), etc.

I want to query all the Answers for a particular Student and Quiz. Is STI still the way to go for this? I am currently using Rails 2.3 but have budgeted about a month to upgrade after Rails 3.0 is released.


The questions and alternatives are going to be stored in the database, right? So basically somebody like a teacher can create a quiz that has many questions, which has many alternatives, and the students take a quiz where he responds to questions by picking alternatives or writing an essay.

What makes this complicated is that there are different types of questions, (multiple choice, single choice, essay), which has consequences for the alternatives and the answers. I think it makes sense to use STI here so that there can be 3 sub-classes of question for each type. Without STI you will need a large amount of if-tests which makes messy code. STI wont make it hard to list questions and answers.

I think the models need to be structured like this:

Quiz has many questions Question has many alternatives

When a student is answering the quiz, he is taking a test.

Test belongs to student Test belongs to quiz Test has many answers Answer belongs to question (one answer per question) Answer has_many chosen_alternatives Chosen_alterntaive belongs to alternative (you might think that chosen_alternative is unnecessary, and that an answer can be hooked directly to an alternative, but this is going to create some issues for the multiple-choice questions). It is always a good idea to keep class names as single words where possible. Calling it "choice" instead of "chosen_alternative" may be better.

Then 3 sub-classes of question: Single, Multiple, Essay. This allows you to put logic in the subclasses and base behaviour on which type the question is. Examples of this would be; when the question is of type single, the student can only pick one alternative, when it is multiple, he can pick many. For the essay version no alternatives are created, hence no chosen_alternative will be created when the student answers. I would store this answer in a text field directly on the answer record. I also suspect that it would be a good idea to use STI on the answers, as some behaviour here will depend on which type the question is. Instead of having a bunch if-tests everywhere checking which type the question is and act accordingly, you can have 3 answer types in parallel with the 3 question types and split the logic that way.

This response became a lot longer than I had planned. I hope some if it is usefull to you.

Thanks, Sharagoz. It is helpful. I guess you answered my big question, which was whether or not STI is still relevant.

The design I've chosen is very similar to the one you describe. I don't have a need for the type of multiple choice that you describe, what I needed was more like what you call Single only the student is presented with options to choose from (i.e. "Choose the best answer from this list"). For that, I'm just going to serialize the list of options into the Question table. I won't need to have the complexity of the chosen_answers you describe. Also, I've renamed my existing classes to have one word as you suggest. I haven't run into any problems yet, but I haven't really gotten too complicated either.

Thanks again.