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.