什么MySQL数据库表和关系将支持有条件问题的问答调查?

我正在研究一个相当简单的调查系统。 数据库模式将变得很简单:一个Survey表,与Question表成一对多的关系,与Answer表和PossibleAnswers表成为一对多的关系。

最近,客户意识到她只想给某些问题提出一些问题的能力,例如, 你是否买了香烟?接下来是什么是你最喜欢的香烟品牌?没有问第二个问题问题不吸烟者)。

现在我开始想知道在我的数据库模式中实现这个条件问题的最好方法是什么? 如果question A有两个可能的答案:A和B,而question B只有在答案为A才会出现在用户面前?

编辑:我正在寻找的是一种方法来将这些有关需求的信息存储在数据库中。 数据的处理可能会在应用程序端完成,因为我的SQL技能很糟糕)

调查数据库devise

最后更新:5/3/2015
图表和SQL文件现在可在https://github.com/durrantm/survey

在这里输入图像说明

如果您使用这个(顶部)答案或任何元素,请添加反馈改进!

这是一个真正的经典,由数千人完成。 他们总是看起来“相当简单”,但要做的很好,其实很复杂。 要在Rails中做到这一点,我会使用附图中显示的模型。 我敢肯定,对于某些人来说,这似乎过于复杂了,但是一旦你build立了其中的一些,多年来,你意识到大部分的devise决策都是非常经典的模式,最好通过dynamic灵活的数据结构解决一开始。
更多细节如下:

关键表的表详细信息

答案

答案表是至关重要的,因为它捕捉用户的实际答复。 你会注意到答案链接到question_options ,而不是问题 。 这是故意的。

input_types

input_types是问题的types。 每个问题只能是一种types,例如所有的无线电拨号,所有的文本字段等。当有(例如)5个无线电拨号时使用额外的问题,并且对于“包括?”,使用1个checkbox。 选项或一些这样的组合。 将用户视图中的两个问题标记为一个,但在内部有两个问题,一个用于无线电拨号,一个用于checkbox。 在这种情况下,checkbox将有一组1。

option_groups

option_groupsoption_choices让你build立“共同的”组。 例如,在一个房地产应用程序中,可能会出现这样一个问题:房产多大? 答案可能在以下范围内:1-5 6-10 10-25 25-100 100+

然后,例如,如果对相邻的房产年龄有疑问,那么调查将要“重复使用”上述范围,以便使用相同的option_group和options。

units_of_measure

units_of_measure就像听起来一样。 无论是英寸,杯子,像素,砖块还是其他东西,您都可以在这里定义一次。

仅供参考:虽然本质上是通用的,但是可以在此基础上创build应用程序,并且此模式非常适合Ruby On Rails框架,并且每个表的主键都使用“id”约定。 此外,这些关系都是简单的one_to_many's,没有many_to_many或has_many throughs需要。 我可能会添加has_many:throughs和/或:delegates,虽然可以很容易地从一个单独的答案中获取诸如survey_name之类的东西,而不需要.multiple.chaining。

你也可以考虑复杂的规则,并且在你的问题表中有一个基于string的条件字段,接受/parsing下面的任何一个:

  • A(1)= 3
  • ((A(1)= 3)和(A(2)= 4))
  • A(3)> 2
  • (A(3)= 1)和(A(17)!= 2)和C(1)

其中A(x)= y表示“问题x的答案是y”,C(x)表示问题x的条件(默认为true)。

这些问题有一个订单字段,你会逐一浏览它们,跳过条件为FALSE的问题。

这应该允许调查任何你想要的复杂性,你的GUI可以自动创build这些“简单模式”,并允许和“高级模式”,用户可以直接input方程。

一种方法是添加一个表的问题要求与领域:

  • question_id(链接到“哪个品牌?”的问题)
  • required_question_id(链接到“你吸烟吗?”的问题)
  • required_answer_id(链接到“是”的答案)

在应用程序中,您在提出某个问题之前检查此表。 使用单独的表格,很容易添加所需的答案(为“有时”答案等添加另一行…)

就个人而言,在这种情况下,我会使用你所描述的结构,并使用数据库作为一个愚蠢的存储机制。 我很喜欢把这些复杂和依赖约束放到应用程序层。

我认为强制执行这些约束的唯一方法是不用为其他外键创build每个问题的新表,而是使用T-SQL或其他供应商特定的机制来构build数据库触发器来执行这些约束。

在应用程序级别,您有更多的可能性,而且更容易移植,所以我更喜欢这个选项。

我希望这会帮助你find你的应用程序的策略。