目前我正在为复杂的测验应用设计数据库（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，即使我可能会添加其他问题类型。然后，当我有完全不同的任务类型时，我可能必须加入更多的表，所以为什么不从一开始就使用单独的表？这基本上就是在伊利亚斯完成的。除了每种类型的表格之外它甚至是一个很大的优势吗？然后，我将只有必须拥有所有任务类型的所有处理程序的任务模型，而不是单独的模型。
哇，这是很多文字......好吧，我需要把它写下来才能看到它。仍然不太确定如何处理它。很高兴收到你的意见！编辑：另一件事......它只是我，或者answer_set表引用了question_id有点奇怪吗？这是正确的方法吗？
答案 0 :(得分：0)
你似乎在寻找一般性建议，而不是具体的答案，所以我会给你一些。
仔细考虑任务和问题之间多对多的需求。我对这种方法有一些担忧： *如果要在特定任务的上下文中编辑问题，可能会无意中使该问题对另一个任务无效。 *根据上下文（任务），问题的答案可能会有所不同吗？ *多对多的额外开销可能是重复使用字符串。
我不太了解你需要对表格进行分类，所以我真的不能说出来。