调查的数据库设计

Question

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

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

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

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

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

   一个简单的例子：

   tblSurvey ：SurveyID

   tblQuestion ：QuestionID， SurveyID ，问题类型，问题

   tblAnswer ：AnswerID， UserID ， QuestionID ，答案

   tblUser ：UserID，UserName

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

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

Answer 1

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

Answer 2

我的设计如下所示。

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

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

Answer 3

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

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

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

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

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

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

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

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

Answer 4

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

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

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

这绝对是要实施的更多工作，所以我真的不会建议这个，除非你肯定知道这个表会遇到大规模的问题。

Answer 5

No 2看起来不错。

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

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

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

Answer 6

第二种方法是最好的。

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

简单的事情是：

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

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

Answer 7

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

Answer 8

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

Answer 9

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

Answer 10

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

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

Answer 11

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

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