嘿，这个问题挺实际的，咱们来拆解下两种方案的优劣，再看看哪种更适配你的业务场景：

现有三表结构的核心优势 #

你当前用的quizzes、questions、answers三表范式化设计，其实是数据库设计里的经典方案，它的好处很明显：

• 数据冗余极低：每一条数据（测验、题目、选项）都是独立存储的，修改某个选项只需要更新answers表的一行记录，不会影响其他数据，维护成本很低。
• 扩展性极强：如果以后业务有变化——比如允许题目超过5个选项、支持多选题（需要标记多个正确答案）、甚至给选项加额外属性（比如图片、提示语），都不用修改表结构，直接新增数据就行。
• 查询统计更灵活：比如要统计某个选项的被选率、筛选包含特定选项的题目，用JOIN语句就能轻松实现，后续做数据报表也更方便。

合并答案到questions表的两种方案分析 #

如果想减少行数，把选项存在questions表里，通常有两种实现方式，咱们分别说：

方案1：用固定字段存储选项（如option1、option2...option5） #

• 优点：查询效率高，不用关联多张表，读取一份测验的所有内容时，一次查询就能拿到所有题目和选项，减少数据库交互次数。单份测验的行数直接降到21行（1条测验记录+20条题目记录），确实精简了很多。
• 缺点：
  • 灵活性极差：如果以后要增加选项数量（比如从5个改成6个），必须修改表结构；如果题目选项少于5个，空字段会浪费存储空间。
  • 维护和统计麻烦：修改某个选项时要更新整个题目记录；如果要统计选项相关的数据（比如哪个选项最受欢迎），SQL语句会非常繁琐，得逐个拆分option字段来处理。

方案2：用JSON字段存储所有选项 #

• 优点：比固定字段灵活，能存储任意数量的选项（只要符合你业务上的最多5个限制），同样能减少行数，单表查询也方便。
• 缺点：
  • 数据库约束弱：无法用SQL直接约束选项的格式、数量，也没法强制标记正确答案，这些校验都得放到业务代码里做，增加了开发成本。
  • 查询性能差：如果要筛选包含特定选项的题目，或者统计选项数据，得用JSON函数来解析，性能远不如普通的JOIN查询，数据量变大后差距会更明显。
  • 索引难优化：JSON字段的索引支持有限，很难针对选项内容做高效索引。

最终建议 #

• 如果你的业务需求完全固定：确定永远不会超过每题5个选项，也不需要做复杂的选项统计，只是快速展示测验内容，那么用固定字段的questions表方案可以考虑，确实能减少行数，提升查询速度。
• 但如果考虑到未来扩展性或者希望数据维护更省心，现有三表的范式化结构其实更优。虽然单份测验的行数多，但MySQL处理这种量级的JOIN查询完全没问题——只要给quizzes.id、questions.quiz_id、answers.question_id这些外键字段加上索引，查询速度会非常快，而且后续业务迭代的成本低很多。

内容的提问来源于stack exchange，提问作者Dppal