哪些 mysql 数据库表和关系将支持带有条件问题的问答调查？ [关闭]

Posted 2023-02-16

【中文标题】哪些 mysql 数据库表和关系将支持带有条件问题的问答调查？ [关闭]

【英文标题】：What mysql database tables and relationships would support a Q&A survey with conditional questions? [closed]

【发布时间】：2010-10-07 03:42:01

【问题描述】：

我现在正在开发一个相当简单的调查系统。数据库模式将很简单：一个Survey 表，与Question 表处于一对多关系，与Answer 表和@987654324 处于一对多关系@表。

最近，客户意识到她希望能够仅向对先前问题给出特定答案的人显示某些问题（例如。你买香烟吗？后面会显示What's你最喜欢的香烟品牌？，向不吸烟的人问第二个问题是没有意义的）。

现在我开始想知道，就我的数据库架构而言，实现这个条件问题的最佳方法是什么？如果question A 有2 个可能的答案：A 和B，并且question B 应该只出现在用户如果答案是A?

编辑：我正在寻找一种将有关需求的信息存储在数据库中的方法。数据的处理可能会在应用程序端完成，因为我的 SQL 技能很烂;)

【问题讨论】：

我每天都在使用调查系统，而您对简化它们所需的复杂性非常感兴趣。

我知道这是一个简单的例子，虽然它正是我项目所需要的；）但是非常欢迎您提供任何额外的意见

@JoePhilllips 你完全正确..

【参考方案1】：

调查数据库设计

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

获得

如果您使用此（顶部）答案或任何元素，请添加有关改进的反馈！！！

这是一部真正的经典作品，由数千人完成。他们总是看起来“相当简单”，但实际上它非常复杂。要在 Rails 中执行此操作，我将使用附图中显示的模型。我敢肯定，这对某些人来说似乎过于复杂，但是一旦你构建了其中的一些，多年来，你就会意识到大多数设计决策都是非常经典的模式，最好通过动态灵活的数据结构来解决一开始。 更多详情如下：

关键表的表详细信息

答案

answers 表格非常重要，因为它记录了用户的实际反应。 您会注意到答案链接指向 question_options，而不是 questions。这是故意的。

输入类型

input_types 是问题的类型。每个问题只能是一种类型，例如所有无线电拨号，所有文本字段等。当有（比如说）5个无线电拨号和1个“包含？”复选框时使用附加问题。选项或一些这样的组合。将用户视图中的两个问题标记为一个，但内部有两个问题，一个用于无线电拨号，一个用于复选框。在这种情况下，复选框将包含一组 1。

option_groups

option_groups 和 option_choices 可让您建立“通用”组。 例如，在房地产应用程序中，可能会出现“房产有多旧？”的问题。 在以下范围内可能需要答案： 1-5 6-10 10-25 25-100 100+

然后，例如，如果有关于相邻财产年龄的问题，那么调查将希望“重用”上述范围，以便使用相同的 option_group 和 options。

units_of_measure

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

仅供参考：虽然本质上是通用的，但可以在此基础上创建应用程序，并且此架构非常适合 Ruby On Rails 框架，其中具有诸如“id”之类的约定每个表的键。此外，这些关系都是简单的 one_to_many，不需要 many_to_many 或 has_many throughs。我可能会添加 has_many :throughs 和/或 :delegates ，以便在没有.multiple.chaining 的情况下轻松地从个人答案中获取survey_name 之类的内容。

【讨论】：

希望我能多次投票 :)

@MichaelDurrant 您如何将它仅用于文本响应？您会提出什么 option_choice 类似“描述您的工作环境”这样的问题

@MichaelDurrant，我目前正在分析您的设计。一些问题一直在我脑海中响起，尽管这使我无法完全理解架构。如果你能回答他们，我真的会得到帮助：1）表 question_options 是否填写在回答或创建问题时？ 2) 为什么问题中的 option_group_id 是可选的？当通过 question_options 和 option_choices 的每个答案都需要一个选项组时。如果这两个都被清除了，让我们看看我是否可以回答我的其他问题。

添加了 V1.6。 修复了应该是 int 而不是 varchar 的外键。添加了 3 个“相关问题/答案”字段来实际回答原始问题...更新了图表和 github，包括创建脚本。通过目录添加语义版本控制。

v1.6 要点gist.github.com/durrantm/1e618164fd4acf91e372

【参考方案2】：

您还可以考虑复杂的规则，并在您的问题表中有一个基于字符串的条件字段，接受/解析其中任何一个：

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 的条件（默认为真）...

问题有一个 order 字段，您将一个一个地检查它们，跳过条件为 FALSE 的问题。

这应该允许您进行任何复杂的调查，您的 GUI 可以在“简单模式”下自动创建这些调查，并允许用户直接输入方程式的“高级模式”。

【讨论】：

哇...在看到这个解决方案后我得到了启发......正是我正在寻找的东西。谢谢。

【参考方案3】：

一种方法是添加一个带有字段的表格“问题要求”：

question_id（链接到“哪个品牌？”问题） required_question_id（链接到“你吸烟吗？”问题） required_answer_id（指向“是”答案的链接）

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

【参考方案4】：

就个人而言，在这种情况下，我会使用您描述的结构并将数据库用作哑存储机制。我喜欢将这些复杂且依赖的约束放入应用程序层。

我认为，在不为每个带有外键的问题构建新表的情况下强制执行这些约束的唯一方法是使用 T-SQL 内容或其他供应商特定机制来构建数据库触发器来强制执行这些约束。

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

我希望这将帮助您为您的应用找到策略。

【讨论】：

我的选项总共只需要一个表格，而不是每个问题都需要新表格

是的，我打算把逻辑放到应用程序中，我不喜欢为每一点逻辑创建存储过程（主要是因为我很烂）。我只是在寻找一种存储需求的好方法。

tehvan，我认为对于更复杂的需求，该解决方案确实缺少一些关键信息。这个领域实际上是关于“专家系统”的，它更适合这个。但现在我想起来，我的解决方案也不会是最好的，因为它并不是真正的动态。