应采用类型驱动设计:questiontype区分题型,答案统一存string/jsonnode;question用surveyid外键;jpa用left join fetch避免n+1;dto接收答案并用@jsonanysetter;选项与答案分表存储。

问卷实体怎么设计才不容易改崩
Java里问卷系统最常踩的坑,是把Question和Answer硬编码成固定字段(比如String optionA、String optionB),结果加个新题型就得改类、改数据库、改前端接口。真正能撑住迭代的模型,得让题型可扩展、答案可动态解析。
建议用「类型驱动」:用questionType字段区分"single_choice"、"multiple_choice"、"text"等,答案统一存为String或JsonNode(用Jackson),而不是拆成一堆列。
-
Question类保留id、content、questionType、options(List<string></string>,只对选择题有意义) -
Response类不存具体答案值,只存questionId和rawValue(String),后端按questionType决定怎么解析rawValue - 避免在
Question里放Survey引用,用外键surveyId代替,否则JPA懒加载容易出N+1
JPA映射一对多时为什么总查出null
新手常把Survey → Question → Answer全设成@OneToMany,结果survey.getQuestions()返回空集合,不是数据没查到,而是没配对FetchType或没触发初始化。
根本原因在于JPA默认LAZY,而你又没在service层调用getQuestions().size()之类触发加载,或者用了findAll()这种不带JOIN的查询。
立即学习“Java免费学习笔记(深入)”;
- 开发阶段快速验证:在
@OneToMany上加fetch = FetchType.EAGER,但上线前必须改回LAZY - 真正该做的是写自定义JPQL:
@Query("SELECT s FROM Survey s LEFT JOIN FETCH s.questions q LEFT JOIN FETCH q.answers WHERE s.id = :id") - 别在
Question实体里再写@ManyToOne(fetch = FetchType.LAZY)指向Survey——循环引用+JSON序列化会直接报StackOverflowError
答案提交时怎么避免JSON格式错乱
前端传来的答案通常是{"q1": "A", "q2": ["X", "Y"], "q3": "其他说明"}这类结构,后端如果用@RequestBody Map<string object></string>接,Object可能是LinkedHashMap也可能是String,转成具体类型时容易ClassCastException。
更稳的方式是定义一个轻量DTO,用Jackson注解控制反序列化行为,而不是靠运行时类型判断。
- 用
@JsonAnySetter捕获所有问题ID,存在Map<string jsonnode></string>里 - 对单选题字段,声明为
String;多选题声明为List<string></string>;文本题也声明为String——Jackson会自动转换,失败则抛HttpMessageNotReadableException - 别在Controller里手动
new ObjectMapper().readValue(),Spring Boot已配置好,直接依赖注入ObjectMapper即可
MySQL里怎么存选项和答案才不锁表
有人把所有选项拼成"A|B|C|D"存VARCHAR,答案存"A,C",看着省事,但查“选了C的所有用户”就得LIKE '%C%',索引失效,数据一过万就卡。
真正兼顾查询和扩展的做法是分表,但不用过度设计:一个question_option表存选项(含排序字段sortOrder),答案单独存response_answer,用(response_id, question_id)联合主键。
-
question_option表必须有question_id索引,否则后台管理加载选项时慢 -
response_answer表别加唯一约束在question_id上——同一份问卷可以有多个同题ID的答案(比如矩阵题) - 如果真要全文搜答案内容,给
response_answer.value加GENERATED COLUMN + FULLTEXT,别直接FULLTEXT原字段
题型逻辑和存储分离这事,一开始想太细会拖进度,但等到要加评分规则、导出Excel、做交叉分析时,模型没留余地就只能推倒重来。










