从零搭建问卷构建器：SQL数据模型过度规范化问题咨询

这问题我之前帮朋友搭问卷系统时踩过一模一样的坑——为了统一模型把所有问题硬塞到模块里，结果库里面一半都是只有一个问题的“假模块”，不仅看着闹心，查数据的时候还多了好多没必要的JOIN。给你几个我实践下来好用的优化思路：

1. 让模块成为「可选关联」，而非强制依赖 #

把questions表中的module_id外键设为可空，彻底打破“每个问题必须属于一个模块”的约束：

• 独立问题（比如单选、文本输入）直接把module_id留空，不需要绑定任何模块；
• 像李克特量表这类需要成组的问题，统一关联同一个模块ID，模块表只存储这类真正需要“组属性”的集合（比如量表的维度名称、统一选项配置、组内问题的排序规则等）。

举个简化的表结构例子：

-- 模块表：只存真正的问题组
CREATE TABLE modules (
  id INT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(100) NOT NULL, -- 比如"产品满意度李克特量表"
  group_type VARCHAR(50), -- 可选，标记组类型：likert_scale / custom_group
  shared_options JSON, -- 可选，存储组内共享的选项（比如李克特的"非常满意"-"非常不满意"）
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

-- 问题表：独立问题无需绑定模块
CREATE TABLE questions (
  id INT PRIMARY KEY AUTO_INCREMENT,
  content TEXT NOT NULL,
  question_type VARCHAR(50) NOT NULL, -- single_choice / likert_item / text_input...
  module_id INT NULL, -- 外键，可空
  options JSON NULL, -- 独立问题的自定义选项；如果是模块内问题，可复用module的shared_options
  sort_order INT DEFAULT 0, -- 问题排序，模块内的问题可以基于此排序
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (module_id) REFERENCES modules(id) ON DELETE SET NULL
);

2. 清理历史冗余数据 #

针对已经存在的大量单问题模块，写个简单的脚本批量处理：

1. 找出所有仅包含1个问题的模块；
2. 将这些模块关联的问题的module_id设为NULL；
3. 标记或删除这些无意义的空模块（如果不需要保留历史痕迹的话）。

这样能快速把数据库里的“垃圾模块”清掉，让数据结构更清爽。

3. 进阶：用关联表实现完全解耦（可选） #

如果后期可能出现“一个问题属于多个模块”的需求（虽然问卷场景少见，但弹性更高），可以彻底去掉questions表的module_id，改用中间关联表：

CREATE TABLE question_module_mappings (
  question_id INT NOT NULL,
  module_id INT NOT NULL,
  sort_order INT DEFAULT 0, -- 问题在模块内的排序
  PRIMARY KEY (question_id, module_id),
  FOREIGN KEY (question_id) REFERENCES questions(id) ON DELETE CASCADE,
  FOREIGN KEY (module_id) REFERENCES modules(id) ON DELETE CASCADE
);

这种方式完全解耦问题和模块，独立问题不需要在关联表中出现，只有成组的问题才会被映射到模块里。缺点是查询模块下的问题时需要多一次JOIN，但对于问卷系统的量级来说，性能影响几乎可以忽略。

最后提个小建议 #

不要为了“规范化”而过度设计——模块的核心价值是共享属性+批量管理，比如李克特量表的统一选项、组内问题的批量排序/编辑，而不是给每个问题套个“容器”。当模块不能提供这些价值时，就让问题独立存在就好，实用永远比“完美规范化”重要。

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