0

假设您在调查中有以下问题，您需要将这些问题转置到数据库中，然后在 webapp 中使用：

在上个周末，您吃了以下哪些？

  • 冰淇淋
  • 沙拉
  • 炸鸡

在上面我们自动建立连接。但是为了让问题在数据库中有意义，它们应该像这样存储吗？：

  • 上周末，你吃冰淇淋了吗？
  • 上周末，你吃沙拉了吗？
  • 上个周末，你吃油炸检查了吗？

假设您正在使用像Micheal's这样的设计，将它们存储在这样的表中似乎是合理的：

[During the last weekend, did you eat ice cream] -> questions_table.question_name
[Yes/No] -> Option_group_table.option_group_name
[Yes][No] -> option_choices_table.option_choice_name
[True or False] -> answers_table.answers_yn

然而，如果你想从这些数据中构建一个网页，它会被杂乱无章地显示：

  • 上周末，你吃冰淇淋了吗？
  • 上周末，你吃沙拉了吗？
  • 上个周末，你吃油炸检查了吗？

前端 webapp 应该解决这个问题吗？通过正则表达式之类的方式？

Function_to_help_properly_display_string("String")

这种方法的缺点似乎是不能以相同的方式处理不同的 questions.question_names （字符串）。例如：

你周末去了以下哪个？

  • 德国
  • 法国

无法像我们最初的问题一样处理。

或者数据库应该考虑到这可能有更多的列？

[Question table]
[question.heading] -> During the last weekend, which of the following did you eat?:
[question.list] -> ice cream
[question.full] -> During the last weekend, did you eat ice cream?

做这样的事情的缺点是它看起来重复和混乱。

他们很可能是我没有展示的第三种选择，请随时分享！提前致谢，

4

1 回答 1

1

我已经为调查做过几次数据库设计/UI设计，这就是我用过的：

表：问题

字段：question_id、question_text、display_order、question_type、必填

请注意，display_order、question_type 和 required 字段都是 UI 的提示。我们没有将问题和答案一起存储在文本中，但我们已经向 Web 开发人员提供了有关如何在 UI 中显示问题的提示。我们告诉他们他们应该出现什么顺序，它是什么类型的问题（复选框/多选-或-单选按钮/一个选择），以及是否需要问题。

表：question_options

字段：question_option_id、question_id、option_text、display_order

这里也一样。我们有一些关于显示顺序和选项文本的 UI 帮助。请注意，使用我们的选项，我们并没有规定 UI 中会发生什么。那是在问题级别举行的。这意味着您可以轻松更改选项的显示方式（下拉菜单、单选按钮、复选框等）

另请注意，我们保留加入问题的能力。

表：答案

字段：user_id、question_id、question_option_id

这只是告诉我们给定用户和给定问题，用户回答了什么。

所有这三种结构都是在数据库中进行调查的良好开端。UI 非常自然地由此而来。您必须编写查询/存储过程才能将数据返回到 Web 应用程序，但这并不难。

（一般来说，我认为尝试将字符串解析作为数据库数据显示的一部分是不明智的。换句话说，我认为尝试使用正则表达式来编写问题/答案以在 UI 中显示是不明智的。模型正确的数据库，您会发现应用程序的其余部分不会很难编码。）

于 2013-01-13T23:51:31.233 回答