【Webman+MySQL答题系统一】项目概述与数据库设计

写在前面

《Webman+MySQL教程》五篇把地基打好了：安装、路由、数据库连接、ORM、JSON 接口。从本系列开始，把这些积木拼成一个完整项目——在线答题系统：学员选卷答题、提交后自动判分、错题可复盘，管理员在后台维护题库与组卷。全系列共 10 篇，代码可直接复制运行。

一、需求拆解

一个最小可用但五脏俱全的答题系统，需求如下：

• 学员端：登录、查看试卷列表、开始答题、逐题作答、提交、查看成绩与错题；
• 题库：支持单选、多选、判断三种题型，题目带选项与标准答案；
• 组卷：管理员把若干题目组成一份试卷，设定总分与及格线；
• 判分：提交后由服务端判分，落库成绩与每题得分明细；
• 统计：平均分、及格率、个人错题本。

拆成模块对照表：

二、整体架构

三层结构：UniApp / 浏览器只跟 Webman API 打交道，所有业务规则都收敛在服务端：

一条铁律：判分必须放在服务端。前端拿到的题目数据里绝不能带标准答案字段，否则一个抓包就能把整份题库答案扒走。第六篇实现取卷接口时会专门体现这一点。

三、数据表设计

6 张表，职责如下（完整建表 SQL 在第三篇给出）：

为什么 record_answer 要单独一张表而不是把答案塞成一个大 JSON？统计错题时按 question_id 聚合、按 is_right 过滤都只要一条 GROUP BY，不必每次解析 JSON。明细行级存储是统计类系统的通用做法。

四、先把判分规则定死

• 单选：选项与答案完全一致得该题分值，否则 0 分；
• 多选：完全一致得满分；多选、错选得 0 分；漏选得一半分（可按需求改成 0 分）；
• 判断：同单选。

规则先写进文档再写代码。第七篇的判分函数就是这几条 if 的事，规则含糊是判分 bug 的最大来源。

五、系列规划

小结

本篇定了需求、架构、表结构与判分规则。下一篇新建 quiz_system 项目，把骨架搭起来。