问卷数据库设计-哪种方法更好?


15

我有一个长长的html页面,几组问题分成小部分(一页中大约有15个子部分),问题总数约为100个问题:输入,选择,复选框,单选按钮,文本区域,和文件上传。一个问题可以包含许多答案,这些答案可以从一组复选框,一组选择列表,一组多重选择中获得,也可以全部组合成一个答案。我以为我会在下面使用这种数据库设计,但是最近发现这毕竟不是一个好方法。

  1. 一位客户只能回答一组问题:每100个问题一位客户。
  2. 对于旧方法,我不在数据库中保留问题,而是在PHP编码中将其分配为常量。问题是我必须比较PHP中的问题,以使其与数据库中的答案同步。如果从PHP更改/删除/移动了一个问题,我肯定会迷失它与问卷数据库中的答案。更好的解决方案?
  3. 我能否将从多个元素中获得的多个答案作为一个答案保存在一个字段中?如何检索此字段并再次显示它以供客户在表单上查看?
  4. 我应该选择以下哪个选项?

选项1:旧方法(1张桌子)

表格:问卷

  • 编号(PK)
  • 客户ID
  • 状态
  • A1
  • A2
  • A3
  • A100

选项2:新方法(2张表)

表格:问题

  • QID(PK)
  • 问题(varchar)

表格:答案

  • 援助(PK)
  • 客户ID
  • QID(int)
  • 答案(varchar)

还是选项3?


您能否添加有关该应用程序的更多信息。-是否动态创建问卷?IE:此调查表应该有这些问题,而另一份调查表应该有其他问题。-问卷问题是否动态?IE:客户可以稍后添加新问题。无论是动态系统还是静态系统,您都必须以不同于1:M Question:Answers的形式存储1:1 Question-Answer结果到数据库中。
Zambonilli 2012年

是和否分别是(动态问题可能在第二阶段的后期,但现在不行。)
模块化的

我已投票决定要关闭这100个问题:输入,选择,复选框,单选按钮,文本区域和文件上传范围太广,无法使用。
埃文·卡罗尔

Answers:


17

绝对不要对您的问卷进行硬编码。使用关系数据库或xml文件。我提出以下表格

  • Questionnaire:问卷的一般描述。标题,调查名称,调查表发布日期,版本等。

  • Section:构成问卷的各个部分。章节编号,章节标题,说明。

  • Question:属于部分的问题。问题编号,问题文本,描述,问题类型(文本,多项选择等)。

  • Question_Choice:属于与单个复选框,单选按钮等相对应的问题的可能答案。选择文本,选择编号,订单。

  • Respondent:回答问题的人员。个人资料,用户号码。

  • Interview:属于一名受访者和一份问卷的访谈,测试或调查(取决于问卷的性质)。如果受访者始终只能回答一张调查表(或者如果调查是匿名的),则此表已过时,可以与“受访者”表合并。面试日期(或测试日期或调查日期),面试官(如果适用)。

  • Answer:答案属于一次采访(或受访者,见上文)和一个问题。回答文本(针对文本类型的问题),选择(针对单选按钮)。

  • Answer_Choice:当可以检查多个选择时,属于一个答案和一个Question_Choice的选择。

这是一种非常规范的方法。但是,您可以根据需要决定将选择串联到一个字符串中,或​​将它们存储为位模式或以其他方式简化。


6

你需要几张桌子

1-问题(问题ID,输入类型,可见,问题类型,问题文本,预期答案...。)

2-答案(问题ID,用户ID,活动ID,答案...)

3-用户(用户ID,用户名...)

4-用于保存问题/答案活动的表格(活动ID,数据/时间,用户ID)

您可能还希望有一个表,该表指定应该对每个活动应用的问题-按用户分组,或者可能是问题集合。外键/主键将是在多个表中具有相同名称的列,应对其进行索引。

如果使用此结构,则无需更改架构或演示文稿代码即可添加问题或用户或更改答案-确保演示文稿代码在运行时动态创建-您只需要添加一条记录在适当的地方。

与硬编码方法相比,这种方法最初可能需要更长的开发时间,但是维护起来却要简单得多,因为您只需更改数据即可更改行为。

(提示,要创建表示层,您将需要一个查询,该查询将获取要显示的适当问题,然后遍历此结果集并调用一种方法在屏幕上呈现要提问的内容,所选择的方法适合于问题的演示文稿(文本框,广播组等))


+1不确定表#4,但总体答案不错。特别是我喜欢从单数表名到复数表的变化,即Question >> Questions。
Leigh Riffel 2012年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.