调查数据库设计

最后更新：5/3/2015

现在可以使用图表和SQL文件 https://github.com/durrantm/survey

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

这是一个真正的经典，由数千个完成。他们总是看起来相当简单，但要做的很好，实际上很复杂。要在Rails中执行此操作，我将使用附件中所示的模型。我相信这对于一些人来说似乎过于复杂，但是一旦建立了其中的几个，多年来，您就意识到大多数设计决策都是非常经典的模式，***通过动态灵活的数据结构来解决开始。

以下更多细节：

关键表的表格详细信息

答案

答案表格至关重要，因为它可以捕获用户的实际回应。
您会注意到答案链接到 question_options ，而不是问题。这是有意的。

input_types

input_types 是问题的类型。每个问题只能是1类，例如所有无线电拨号，所有文本字段等。当有（包括）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 无论是英寸，杯子，像素，砖块还是其他的，您可以在这里定义一次。

FYI：尽管通用性本质上可以创建一个应用程序，并且此模式非常适合于具有每个表主键的id约定的 Ruby On Rails 框架。此外，关系都是简单的one_to_many，没有many_to_many或has_many通过需要。我可能会添加has_many：通过和/或：代理，以便从个人答案中轻松获取survey_name，而不需要使用。

I'm working on a fairly simple survey system right now. The database schema is going to be simple: a Survey table, in a one-to-many relation with Question table, which is in a one-to-many relation with the Answer table and with the PossibleAnswers table.

Recently the customer realised she wants the ability to show certain questions only to people who gave one particular answer to some previous question (eg. Do you buy cigarettes? would be followed by What's your favourite cigarette brand?, there's no point of asking the second question to a non-smoker).

Now I started to wonder what would be the best way to implement this conditional questions in terms of my database schema? If question A has 2 possible answers: A and B, and question B should only appear to a user if the answer was A?

Edit: What I'm looking for is a way to store those information about requirements in a database. The handling of the data will be probably done on application side, as my SQL skills suck ;)

Survey Database Design

Last Update: 5/3/2015
Diagram and SQL files now available at https://github.com/durrantm/survey

If you use this (top) answer or any element, please add feedback on improvements !!!

This is a real classic, done by thousands. They always seems 'fairly simple' to start with but to be good it's actually pretty complex. To do this in Rails I would use the model shown in the attached diagram. I'm sure it seems way over complicated for some, but once you've built a few of these, over the years, you realize that most of the design decisions are very classic patterns, best addressed by a dynamic flexible data structure at the outset.
More details below:

Table details for key tables

answers

The answers table is critical as it captures the actual responses by users. You'll notice that answers links to question_options, not questions. This is intentional.

input_types

input_types are the types of questions. Each question can only be of 1 type, e.g. all radio dials, all text field(s), etc. Use additional questions for when there are (say) 5 radio-dials and 1 check box for an "include?" option or some such combination. Label the two questions in the users view as one but internally have two questions, one for the radio-dials, one for the check box. The checkbox will have a group of 1 in this case.

option_groups

option_groups and option_choices let you build 'common' groups. One example, in a real estate application there might be the question 'How old is the property?'. The answers might be desired in the ranges: 1-5 6-10 10-25 25-100 100+

Then, for example, if there is a question about the adjoining property age, then the survey will want to 'reuse' the above ranges, so that same option_group and options get used.

units_of_measure

units_of_measure is as it sounds. Whether it's inches, cups, pixels, bricks or whatever, you can define it once here.

FYI: Although generic in nature, one can create an application on top of this, and this schema is well-suited to the Ruby On Rails framework with conventions such as "id" for the primary key for each table. Also the relationships are all simple one_to_many's with no many_to_many or has_many throughs needed. I would probably add has_many :throughs and/or :delegates though to get things like survey_name from an individual answer easily without.multiple.chaining.