调查的数据库设计[关闭]

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

我提出了两种可能的解决方案：

1. 创建一个巨大的表，其中包含每个调查提交的答案。每列将对应于调查的答案。即SurveyID，Answer1，Answer2，Answer3

   我不认为这是最好的方法，因为此调查中存在很多问题，并且如果要更改该调查似乎不太灵活。

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

   一个简单的例子：

   tblSurvey：SurveyID

   tblQuestion：QuestionID，SurveyID，QuestionType，问题

   tblAnswer：AnswerID，UserID，QuestionID，Answer

   tblUser：用户ID，用户名

   我的问题是答案可能很多，这会使答案表非常庞大。我不确定性能方面是否如此出色。

我将不胜感激任何想法和建议。

我认为您的模型2很好，但是您可以看一下更复杂的模型，该模型可以存储问题和预制答案（提供的答案），并允许它们在不同的调查中重复使用。

-一项调查可能有很多问题；一个问题可以在许多调查中重复使用。
-对于许多问题，可以提供一个（预制）答案。一个问题可以提供许多答案。一个问题可以在不同的调查中提供不同的答案。可以为不同调查中的不同问题提供答案。默认为“其他”答案，如果某人选择其他答案，则其答案会记录在Answer.OtherText中。
-一个人可以参加许多调查，一个人只能回答一次调查中的特定问题。

我的设计如下所示。

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

脚本和mysql workbench.mwb文件也可从https://github.com/durrantm/survey获得。

绝对是选项2，我也认为您可能对当前模式有所疏忽，可能需要另一个表：

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

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

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

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

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

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

数据库旨在存储大量数据，并且大多数都可以很好地扩展。不再真正需要使用较小的标准格式来节省空间。

通常，基于用户可能更改的内容（例如向调查中添加问题）来修改架构应该被认为是相当麻烦的。在某些情况下，它是适当的，尤其是在处理大量数据时，但是在您下潜之前要先了解一下。每项调查只有一个“答复”表，意味着添加或删除问题的成本可能非常高。 ，并且以与问题无关的方式进行分析非常困难。

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

1. 如2中所述，创建详细的响应表来存储每个问题的响应。通常不会从您的应用程序直接查询此数据，而是将其用于生成报告表的摘要数据。您可能还希望对这种数据实施某种形式的归档或删除。
2. 如果需要，还可以从1创建响应表。每当用户希望看到简单的结果表时，都可以使用此方法。
3. 对于出于报告目的需要进行的任何分析，请计划作业以基于来自1的数据创建其他摘要数据。

这绝对是要执行的工作，因此，除非您确定该表将要引起大规模关注，否则我真的不建议这样做。

第二种方法是最好的。

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

简单的事情是：

• 放置数据库并登录到自己的磁盘上，默认情况下并非全部在C上
• 创建所需大小的数据库，以便在数据库增长时不会暂停

我们在SQL Server表中有10个数百万行的日志表。

2号看起来不错。

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

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

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

看起来很完整，适合进行问卷调查。不要忘记为“开放价值”添加表格，客户可以在其中通过文本框表达自己的意见。用外键将该表链接到您的答案，并将索引放在所有关系列上以提高性能。

2号是正确的。除非发现性能问题，否则请使用正确的设计。大多数RDBMS的表狭窄但很长不会有问题。

拥有一个大的Answer表本身并不是问题。只要索引和约束定义明确，就可以了。您的第二个方案对我来说很好。

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

我不知道巨大有多大，但它应该毫无问题地容纳数百万个答案。

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

不确定您的要求，但是这种方法在某些情况下会起作用。