mysql - 哪种数据库设计适合复杂的测验应用程序？

Question

目前我正在为一个复杂的测验应用程序设计一个数据库 (mysql) 架构。我目前正处于提问阶段，并且对表格设计有些挣扎。这是我到目前为止得到的:

问题

task

id  type        etc.
1   mpc
2   text-input
3   matching
4   fill-gaps

task_to_question

task_id     question_id
1           10
2           20
3           30
3           31
3           32
4           40

answer_set ->(task_to_question)

id  question_id answer_id   correct
1   10          100         1
2   10          101         0
3   10          102         0
4   10          103         0
5   20          100         1
6   20          200         1
7   30          100        (1)
8   31          300        (1)
9   32          301        (1)
10  40          100         1
11  40          400         1
12  40          401         1


addon

answer_set_id   gap_number
10               1
11               1  
12               2

这个想法是任务表只有一些基本信息和决定如何处理任务的类型字段。 所有任务都在同一张表中；每个任务都有一个或多个问题 (task_to_question)，具体取决于类型，例如mpc 有一个问题，但是你必须匹配问题和答案的任务有 4 个问题。同样，每个问题都可以有多个答案 (answer_set) - 对于一个或两个单词的文本输入尤其重要。因此，即使在任务类型中，问题和答案的数量也是流动的。这当然可以在以后进行限制，也可以添加子类型。 最后一张表仅在任务类型不能由简单字段类型处理时才加入。在此示例中，我需要在“填充文本中的空白”任务中定义空白的顺序。这可以是一个插件表，甚至可以是针对不同任务类型的多个表(以减少开销)

我这样做的目的是尽可能多地重复使用文本字符串。因此，我可以为 mpc、输入、填补空白甚至部分匹配任务使用相同的问题文本和相同的答案字符串。同样，我认为收集自动完成字段的建议将很容易，而无需对重复项进行排序。

可是越想越觉得其实也太心塞了。我已经看到的问题是例如当一个问题只有正确答案或没有答案时，我已经有一些冗余 - 正确的列变得多余。而且我的答案必须是 varchar，即使我可能会添加其他问题类型。然后，当我有截然不同的任务类型时，我可能不得不加入更多的表，那么为什么不从一开始就使用单独的表呢？ Ilias 基本上就是这样做的。摆脱每种类型的表格甚至是一个很大的优势吗？再一次，我将只有任务模型，它必须具有所有任务类型的所有处理程序，而不是单独的模型。

哇，文字太多了……好吧，我需要把它写下来才能看到完整的内容。仍然不太确定如何处理它。输入很高兴感谢!

编辑:另一件事...是我的问题，还是 answer_set 表引用 question_id 有点奇怪？这是正确的做法吗？

Answer 1

你似乎在寻找一般性的建议是想法而不是具体的答案，所以我会给你一些我的。

仔细考虑任务和问题之间多对多的需求。我对这种方法有一些担忧: * 当您想在特定任务的上下文中编辑问题时，可能会无意中使该问题对另一个任务无效。 * 是否可以根据上下文(任务)让不同问题的答案不同？ * 多对多增加的开销可能与字符串的重用有关。

我不太了解您对表格进行子类型化的需求，所以我真的不能说。