我正在设计一个数据库模式来支持用户可以提交请求的业务案例(代表他/她自己或代表其他人)。要处理并完成请求,提交者将根据他们对先前问题的回答提示问题。也就是说,下一个问题是根据当前问题的答案有条件的。
每个问题都有一个关联类型,它将驱动该特定问题的用户表单。类型布尔的问题表示答案的是/否单选按钮。类型多重的问题表示多项选择答案,用户将从中选择多个电台选项之一。
我有两个问题:
我的question_relationships表将让我指出问题1是问题5的父级,问题5是问题6的父级。但我真的需要答案来推动这种逻辑。
question
-id
-question_name
-question_text
-question_hint
-question_type (boolean, multiple)
question_relationship
-id
-fk_parent_question_id
-fk_child_question_id
request
-id
-person_id
-submitter_id
-submit_date
-status
request_answer
-id
-fk_request_id
-fk_question_id
-answer_text
-answer_boolean
我在db design - survey/quiz with questions and answers看到了答案,但我相信我的情况有点不同。
答案 0 :(得分:0)
一个表有一个相关的填充(命名)空白语句又名谓词。将其变为真实陈述的行将列入表格中。使其成为虚假陈述的行不会出现。这就是我们如何解释表(基础,视图或查询)和更新基础。每个表都代表一个应用程序关系。
(所以2的谓词式引用是如何给出一个表格的意思。因为JOIN的含义是参数意义的AND,而UNION是OR,EXCEPT是AND NOT, etc。)
- 如何将架构修改为" link"多项选择的答案 问题吗? (即"以下答案可用于问题X。")
醇>
// question [question_id] has available answer [answer_id]
question_answers(question_id, answerid)
- 答案如何驱动下一个问题? (即#34;对于问题#1,如果选择答案A,那么GOTO问题5")
醇>
// for question [this_id] if answer [answer_id] is chosen then go to question [next_id]
next_question(this_id, answer_id, next_id)
PS
通过表格表示图形(nodes with edges between them)的方法有很多种。这里的节点是问题,边缘是下一个问题对。不同的表支持不同类型的图形和不同的读取和更新模式。 (我选择了一个反映你的应用程序,但是我自己的答案是通过适当的设计帮助你找到最佳代表。)
PPS
如果通过问题的不同用户跟踪可能意味着哪个问题跟随另一个问题是依赖于上下文的:
// in context [this_id] if answer [answer_id] is chosen then go to context[next_id]
next_context(this_id, answer_id, next_id)
什么" context"取决于您没有给出的应用程序的方面。您所提供的内容表明您唯一的背景概念是当前的问题。此外,根据上下文包含的内容,此表可能需要规范化。您可能需要关于当前上下文与当前问题的独立概念。 (主题:finite state machines。)