Answers.Body: <p>I think this is the best way to model the data, and it lends itself very well to how Craft work. </p>
  
  <p>I guess the only reason to go with the Matrix approach instead, would be to ease how the information is published in the control panel. In some cases it might be easier to just publish one question with all the answers, instead of one question and all the answers seperately. But it's hard to say, not knowing the actual content and amount of data. </p>
  
  <p>It would definitely be possible to go for the Matrix solution too, but it might be a bit more complex to use in your templates, and maybe less efficient. But again, depends on your actual case.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-02-20T22:07:43.073Z
Answers.Text: +1 on this approach. As a side note, you might want to check out a nice plugin called [introvert](https://github.com/iainurquhart/craft_introvert) so that you can display the reverse related answers on the question entry in the CP (for display and easy linking only).
Answers.UserDisplayName: Douglas McDonald
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-02-21T14:03:41.240Z
Answers.Text: Yeah, I tried to do a trail run using the matrix fields and it's kind of crazy to pull in that manner. But I do see how it'd be easier to enter in the data all at once.
Answers.UserDisplayName: Dennis Eusebio
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-02-20T14:11:10.540Z
Answers.LastActivityDate: 2015-02-20T14:11:10.540Z
Answers.UserDisplayName: André Elvan
Answers.Body: <p>Personally I wouldn't relate questions and answers from the answer, I'd relate them from the <strong>question</strong>.</p>
  
  <p>If I understand your concept here, questions <em>might</em> have more than one answer, but an answer can't answer more than one question?</p>
  
  <p>If that's the case, I'd set up 3 channels:</p>
  
  <ul>
  <li>Questions</li>
  <li>Answers</li>
  <li>Candidates</li>
  </ul>
  
  <p>And in your Questions channel, I'd have a <code>relatedAnswers</code> entry field, so answers can be assigned that way.</p>
  
  <p>Everything else I'd keep the same as you have suggested, but with a <code>relatedAnswers</code> field, <code>relatedQuestion</code> would no longer be needed.</p>
  
  <p>You have to also remember that a Candidate might answer more than one question. So having their information in a matrix field on the answer entry would mean a lot of repeated data.</p>
  
  <p>Set up a Candidates channel with entries for each candidate, and add a <code>relatedCandidates</code> entry field to your answer entries so the candidate(s) can be assigned that way.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-02-20T15:38:47.160Z
Answers.Text: What are the benefits on having a relatedAnswers field on Question, instead of a relatedQuestion field on an Answer? The way I see it, this would just make it more work to publish an Answer. You'd have to publish the Answer entry, then find the Question entry, and then find and add the Answer you created to the relatedAnswers field. Instead of just publish the entry. Since an Answer is related to only one Question, I don't really see the benefit.
Answers.UserDisplayName: André Elvan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-02-20T15:50:27.803Z
Answers.Text: @AndréElvan Yeah that's a fair point. I guess, as you said in your answer it comes down to the amount of content for answers. It's hard to say without the specifics.
Answers.UserDisplayName: Jamie Wade
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-02-20T14:11:33.033Z
Answers.LastActivityDate: 2015-02-20T14:18:12.340Z
Answers.LastEditDate: 2015-02-20T14:18:12.340Z
Answers.UserDisplayName: Jamie Wade
Body: <p>I have a site that has these different types of content:</p>
  
  <ul>
  <li>Candidates</li>
  <li>Questions</li>
  <li>Answers</li>
  </ul>
  
  <p>So there's a list of questions, that have answers that are related to a candidate. I imagine the models look like:</p>
  
  <p>Question</p>
  
  <ul>
  <li>Question Info</li>
  </ul>
  
  <p>Answers</p>
  
  <ul>
  <li>relatedCandidate</li>
  <li>relatedQuestion</li>
  </ul>
  
  <p>Candidate</p>
  
  <ul>
  <li>Candidate Info</li>
  </ul>
  
  <p>The main question is is this the best setup for this particular situation? Or should  I have a matrix in Questions with all the answers and then a related field for the candidate and the answer?</p>
  
  <p>While this works if the question section works on it's own, if I ever need to display candidates and then their corresponding answers, I don't know if I can run through the Questions' matrix field and find only that candidate's answer.</p>
  
Tags: <matrix><relations>
Title: How to model a multiple relation situation?
ThreadText: # How to model a multiple relation situation?
  
  (Asked by: username_0 on 2015-02-20)
  
  I have a site that has these different types of content:
  
  * Candidates
  * Questions
  * Answers
  
  So there's a list of questions, that have answers that are related to a candidate. I imagine the models look like:
  
  Question
  
  * Question Info
  
  Answers
  
  * relatedCandidate
  * relatedQuestion
  
  Candidate
  
  * Candidate Info
  
  The main question is is this the best setup for this particular situation? Or should I have a matrix in Questions with all the answers and then a related field for the candidate and the answer?
  
  While this works if the question section works on it's own, if I ever need to display candidates and then their corresponding answers, I don't know if I can run through the Questions' matrix field and find only that candidate's answer.
  
  **Tags:** matrix, relations
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2015-02-20. Score: 3 | Accepted answer
  
  I think this is the best way to model the data, and it lends itself very well to how Craft work.
  
  I guess the only reason to go with the Matrix approach instead, would be to ease how the information is published in the control panel. In some cases it might be easier to just publish one question with all the answers, instead of one question and all the answers seperately. But it's hard to say, not knowing the actual content and amount of data.
  
  It would definitely be possible to go for the Matrix solution too, but it might be a bit more complex to use in your templates, and maybe less efficient. But again, depends on your actual case.
  
  > **Comments:**
  > **username_2**: +1 on this approach. As a side note, you might want to check out a nice plugin called [introvert](https://github.com/iainurquhart/craft_introvert) so that you can display the reverse related answers on the question entry in the CP (for display and easy linking only).  
  > **username_0**: Yeah, I tried to do a trail run using the matrix fields and it's kind of crazy to pull in that manner. But I do see how it'd be easier to enter in the data all at once.  
  
  ---
  
  ### Answer by username_3 on 2015-02-20. Score: 1
  
  Personally I wouldn't relate questions and answers from the answer, I'd relate them from the **question**.
  
  If I understand your concept here, questions *might* have more than one answer, but an answer can't answer more than one question?
  
  If that's the case, I'd set up 3 channels:
  
  * Questions
  * Answers
  * Candidates
  
  And in your Questions channel, I'd have a `relatedAnswers` entry field, so answers can be assigned that way.
  
  Everything else I'd keep the same as you have suggested, but with a `relatedAnswers` field, `relatedQuestion` would no longer be needed.
  
  You have to also remember that a Candidate might answer more than one question. So having their information in a matrix field on the answer entry would mean a lot of repeated data.
  
  Set up a Candidates channel with entries for each candidate, and add a `relatedCandidates` entry field to your answer entries so the candidate(s) can be assigned that way.
  
  > **Comments:**
  > **username_1**: What are the benefits on having a relatedAnswers field on Question, instead of a relatedQuestion field on an Answer? The way I see it, this would just make it more work to publish an Answer. You'd have to publish the Answer entry, then find the Question entry, and then find and add the Answer you created to the relatedAnswers field. Instead of just publish the entry. Since an Answer is related to only one Question, I don't really see the benefit.  
  > **username_3**: @username_1 Yeah that's a fair point. I guess, as you said in your answer it comes down to the amount of content for answers. It's hard to say without the specifics.  
  
  ---
  
  