0

I need to make a recommendation questionnaire, where answering a bunch of questions would lead to some unique result; decisions along the way should affect the end result.

It's fine to make it very basic - so I have two models - Questions and Answers. Each question has two answers, and each of the answers leads to one other question - so graphing out the hieararchy ends up like sort of like a binary tree:

          Question 1
         /         \
    Answer 1      Answer 2
      /              \
 Question 2        Question 3
  /       \         /       \
Ans3     Ans4     Ans5     Ans6
...

So in plain english I'd say that each question has many answers, and each answer has one parent question and has one child question.

For a typical has many relationship, with the little experience I have I would probably just put the foreign key on the many end and not worry about the one end; so here Answer would get a question_id which doesn't have to be unique.

For has_one relationship, either end of relationship seems fine - but I already have a question_id on the answer; so maybe putting "parent" answer's answer_id on the question is appropriate, but that seems mighty confusing lexically - looking up something like Question.answer I would not intuitively understand it's the response that led to this question...

Alternatively, I could have two question_ids on in the Answer model - but then would have to differentiate between which one is "parent question" and which one is "follow-up question"...

Another consideration is that when I fetch the "next question" from the database (based on the answer), I also want to get the possible answers to display. Although optimizing the performance is not a requirement, it would be nice to "do it right" (or at least not completely wrong).

What's the best approach?

apprenticeDev
  • 8,029
  • 3
  • 23
  • 25
  • each question has multiple answers and each answer has one parent question and may have one (or no, if it's the end of the questionnaire) next question – Beth Nov 14 '17 at 20:57

1 Answers1

0

With a bit of help from my friends, found the right term for what I'm trying to save - it's a decision tree!

https://en.wikipedia.org/wiki/Decision_tree

Then on this answer to a similar question https://stackoverflow.com/a/5278239/1592915 suggests using approach of a basically a man-to-many relationship between questions, where answers table is the intermediary.

apprenticeDev
  • 8,029
  • 3
  • 23
  • 25
  • 1
    You are interested in ternary relation(ship)/association "question Q with answer A leads to question R". Whether you can decompose it depends on what exactly "question" & "answer" mean. If Q & A are unique ids & in a *tree* then you can instead use projections "answer A answers question Q" & "answer A leads to question R". PS "Has" is useless as a name, it means "is related to" but doesn't describe *what* relationship. When we know what relationship, it is useful shorthand. A FK is an instance/edge in yet *another* (meta) relationship/dag per legal situations. Forget about them in design. – philipxy Nov 15 '17 at 14:14
  • Thanks for the comment, really good point on the term "has" having very limited use! – apprenticeDev Nov 15 '17 at 17:28