调查的数据库设计

时间:2009-11-19 16:07:35

标签: sql database-design

我需要创建一个调查,其中答案存储在数据库中。我只是想知道在数据库中实现这个的最佳方法是什么,特别是所需的表。调查包含不同类型的问题。例如:评论的文本字段,多项选择题以及可能包含多个答案的问题(例如,检查所有适用的答案)。

我想出了两个可能的解决方案:

  1. 创建一个包含的巨型表 每个调查的答案 提交。每列都会 对应于答案 调查。即SurveyID,Answer1, 答案2,答案3

    我不认为这是最好的方法 因为有很多问题 在这次调查中似乎并不是很好 如果调查要改变,则灵活。

  2. 我想到的另一件事是 创建问题表和答案 表。问题表会 包含所有问题 调查。答案表将包含 来自调查的个人答案, 每一行都链接到一个问题。

    一个简单的例子:

    tblSurvey :SurveyID

    tblQuestion :QuestionID, SurveyID ,问题类型,问题

    tblAnswer :AnswerID, UserID QuestionID ,答案

    tblUser :UserID,UserName

    我的问题在于那里 会有很多答案 使答案表非常庞大。 我不确定它是如此之大 来表演。

  3. 我很感激任何想法和建议。

11 个答案:

答案 0 :(得分:110)

我认为您的模型#2很好,但您可以查看存储问题和预先答案(提供的答案)的更复杂的模型,并允许它们在不同的调查中重复使用。 />
- 一项调查可能有很多问题;在许多调查中可以(重新)使用一个问题。
- 可以为许多问题提供一个(预先制定的)答案。一个问题可以提供许多答案。一个问题可以在不同的调查中提供不同的答案。可以在不同的调查中为不同的问题提供答案。有一个默认的“其他”答案,如果一个人选择其他人,她的答案会记录在Answer.OtherText中。
- 一个人可以参加许多调查,一个人只能在调查中回答一次具体问题。

survey_model_02

答案 1 :(得分:46)

我的设计如下所示。

最新的创建脚本位于https://gist.github.com/durrantm/1e618164fd4acf91e372

脚本和mysql workbench.mwb文件也可用于 https://github.com/durrantm/survey enter image description here

答案 2 :(得分:17)

肯定是选项#2,我认为你可能在当前架构中有疏忽,你可能想要另一个表:

+-----------+
| tblSurvey |
|-----------|
| SurveyId  |
+-----------+

+--------------+
| tblQuestion  |
|--------------|
| QuestionID   |
| SurveyID     |
| QuestionType |
| Question     |
+--------------+

+--------------+
| tblAnswer    |
|--------------|
| AnswerID     |
| QuestionID   |
| Answer       |
+--------------+

+------------------+
| tblUsersAnswer   |
|------------------|
| UserAnswerID     |
| AnswerID         |
| UserID           |
| Response         |
+------------------+

+-----------+
| tblUser   |
|-----------|
| UserID    |
| UserName  |
+-----------+

每个问题可能会有一定数量的答案供用户选择,然后实际答案将在另一个表中进行跟踪。

数据库旨在存储大量数据,而且大多数都可以很好地扩展。没有必要使用较小的normal form只是为了节省空间。

答案 3 :(得分:3)

作为一般规则,根据用户可能更改的内容(例如向调查添加问题)修改架构应该被认为是相当臭的。在某些情况下,它可能是合适的,特别是在处理大量数据时,但在您潜入之前知道您正在进行的操作。每次调查只需要一个“响应”表,这意味着添加或删除问题可能会非常昂贵,并且以与问题无关的方式进行分析非常困难。

我认为你的第二种方法是最好的,但是如果你确定你会有很多规模问题,那么过去对我有用的一件事是混合方法:

  1. 创建详细的响应表以存储每个问题的响应,如您在2中所述。通常不会从您的应用程序直接查询这些数据,但会用于生成报告表的摘要数据。您可能还希望对此数据实施某种形式的归档或删除。
  2. 如有必要,还可以从1创建响应表。只要用户想要查看结果的简单表格,就可以使用此功能。
  3. 对于需要为报告目的而进行的任何分析,请根据1中的数据计划作业以创建其他摘要数据。
  4. 这绝对是要实施的更多工作,所以我真的不会建议这个,除非你肯定知道这个表会遇到大规模的问题。

答案 4 :(得分:1)

No 2看起来不错。

对于只有4列的表,它应该不是问题,即使有几百万行也是如此。当然,这取决于您使用的数据库。如果它像SQL Server那样,那就没问题了。

您可能想在tblAnswer表的QuestionID字段上创建索引。

当然,您需要指定正在使用的数据库以及估计的数量。

答案 5 :(得分:1)

第二种方法是最好的。

如果您想进一步规范化,可以为问题类型创建一个表

简单的事情是:

  • 放置数据库并登录自己的磁盘,而不是全部使用C作为默认值
  • 根据需要创建数据库,以便在数据库增长时没有暂停

我们在SQL Server Table中有10万行的日志表。

答案 6 :(得分:0)

对于smiple调查看起来非常完整。不要忘记为“开放值”添加表格,客户可以通过文本框提供他的意见。将该表与外键链接到您的答案,并在所有关系列上放置索引以提高性能。

答案 7 :(得分:0)

2号是正确的。除非您检测到性能问题,否则请使用正确的设计。大多数RDBMS都不会对一个很窄但很长的表有问题。

答案 8 :(得分:0)

拥有一个大的答案表本身并不是问题。只要索引和约束定义得很好,你应该没问题。你的第二个架构对我来说很好。

答案 9 :(得分:0)

给定正确的索引,您的第二个解决方案将被规范化,并且适用于传统的关系数据库系统。

我不知道有多大是巨大的,但它应该毫无问题地保持几百万个答案。

答案 10 :(得分:-1)

您可以选择将整个表单存储为JSON字符串。

不确定您的要求,但这种方法在某些情况下会有效。