首先，让我们同意否定将HTML存储在数据库中的想法，除了可能只有一些标签（例如换行符，粗体，强调和下划线）仅用于问题的文本。如果将重点放在调查的文本/语义上，而不是
查看 详细信息，那么定义调查和利用其输出将容易得多。
为了支持View（“布局”）配置，可以使用CSS。这将键入问题的ID，该ID将用作View决定存储问题的div（或其他html容器）的ID。在问题记录中也可以列出一些类名，但是用CSS定义。
在建议的数据库模式上，重要的东西似乎已经存在。但是，我看不到提交的响应存储在哪里；是在“提交+提交详细信息”表中？如果是这样，则将MULTIPLE响应类型存储在哪里，它们是否将转换为文本并转换为给定答案？（我认为他们不应该这样做，除非我们更喜欢在竞选期间修改调查后捕获稍有不同的价值。）
一些缺少的属性和想法：
- 应该使多个（或另一种类型）能够 支持“单选按钮”类型选择 （“仅一个”）。一种可能的方法是在类型中添加一个属性，定义允许的最大选择数，这是一种常见的调查内容：“在以下项中选择3个…”
- 问题记录可以具有“广告系列”或 SurveyID ，从而可以在同一商店中存储多个调查。
- 不必太花哨， 可以将 某些 问题 假定 为先前的“布尔”类型的问题 。（如果被调查者对拥有自己的汽车回答“否”，请不要询问换油的频率…）这可以由问题ID和响应值（“通用文本”来定义）。
- 问题表：添加一个“ 页码 ”，以便对问题进行分组（除非在问题容器概念（例如“调查”或“广告系列”）中定义了此信息）
- 问题表：添加“ 序列号 ”以允许以预定的顺序获取问题（除非此类来自“调查/活动”表，此处未显示）
- q_multiplechoice ：（或列出给定MULTIPLE CHOICE的选项的任何表；我怀疑该表将其字段显示为问题中的showin。）添加 序列号 ，从而允许以特定顺序列出选项。
