问卷数据库最容易在第一次改题时暴露问题：第一版 Q6 是单选“最常用的渠道”，第二版允许多选并新增“合作伙伴”；旧答卷中的数字3代表“线下门店”，新答卷中的3却可能只是第三个被选项。如果数据库只保存 q6=3，值还在，题意已经丢了。
长期维护的问卷数据应把“回答发生时看到了哪版问题、回答域是什么、一次答卷可以产生几条值”作为核心关系。一个稳妥的默认方案是：版本化问卷元数据用关系表管理，原始提交保留不可变载荷，标准答案进入带类型和约束的长表，分析宽表按指定版本生成。宽表仍然有用，但更适合作为分析产物，而不是跨项目的唯一事实源。
先决定数据库要保住什么，而不是先决定有几张表
数据库至少要支持三个时间尺度。提交当下，需要完整接收一份答卷，即使网络重试也不能重复计数；项目分析时，需要按题目、选项、批次和人群稳定查询；半年后，需要解释旧值当时代表什么，并把报告数字追到真实回答。若还有多语言、矩阵、循环组、配额、跨期追踪或删除请求，单张宽表很快会把这些差异压进列名和空值里。
可以先写六条验收查询，再画结构：
- 给定答卷标识，找出它实际使用的问卷版本及当时展示的完整题文；
- 给定一道多选题，区分“展示但未选”“未展示”和“整份答卷中断”；
- 给定矩阵或循环题，恢复第几行、第几个对象的回答，而不覆盖前一次；
- 合并两个版本时，指出哪些变量可直接比较、哪些发生了回答域变化；
- 从分析宽表的某一列回到原始回答和标准化规则；
- 执行访问或删除流程时，定位身份信息、答卷、附件和下游副本的关系。
结构能回答这些问题，才算符合研究使用；“能把 JSON 存进去”只是写入成功。
七类实体构成一个够用的关系骨架
study
└── instrument_version
├── question_version
│ └── option_version
└── collection_batch
└── response
├── answer
│ └── answer_choice
└── raw_submissionstudy 表示研究项目和目标总体；instrument_version 保存一次已发布、不可静默改写的问卷版本；question_version 保存问题意图、题文、类型、顺序和显示条件；option_version 保存稳定选项标识、显示标签与顺序。题号只是某版本中的位置，不应成为跨版本唯一标识。
collection_batch 记录渠道、时间与样本上下文；response 表示一次提交或作答会话，并直接引用问卷版本和批次；answer 保存单值、文本、数值、日期或结构性缺失；多选项放入 answer_choice，每个实际选择一行。raw_submission 保存接收时的原始载荷或其受控位置，用于重放和审计，不直接承担日常分析。
DDI Alliance 的DDI-Lifecycle覆盖从问卷与问题到逻辑记录、物理记录和存储的研究数据生命周期，并把可复用对象设计为可识别和可版本化。数据库不必照搬其完整模型，但“问题意图、展示题文、回答域、版本”应被分开理解，而不是塞进一个会被覆盖的 question_text 字段。
同一个多选回答，三种存法会带来三种后果
假设受访者对“用过哪些渠道”选择了官网和线下门店。
宽表拆列可以存为 channel_web=1、channel_store=1。分析直观，导入统计软件方便；但新增选项就新增列，未选和未展示容易都变成0，跨问卷复用与循环题也很笨重。一次性、题目固定且只为一份分析交付时，它可以是合理终点。
数组或 JSON可以存为 ["web","store"]。它忠实保留一次提交的集合，写入灵活，也适合原始层；但若全部答案都只存 JSON，外键、类型、选项合法性和跨项目查询会更难落实。JSON 不是错误，拿它替代所有语义约束才是问题。
选择明细表为官网和门店各建一行，并通过外键引用该题当时的选项版本。它便于校验合法选项、统计选择和处理新增选项；代价是分析前需要聚合或透视。混合模型通常同时保留原始集合和规范化选择行，再为分析生成拆列视图。
无论哪种存法，都要另外表达“问题是否展示”。多选表中没有某选项行，只说明没有记录到选择，不能自动判断受访者看过题目。可以通过问卷逻辑和答卷路径推导，也可以在复杂场景保存 question_exposure 事件；关键是不要把不存在的一行直接编码成否定回答。
不要建一个没有类型的万能 EAV 答案表
最简长表常被设计为 response_id + question_id + value_text，所有内容都转成字符串。这虽然能接住任何题型，却会让日期、金额、量表和缺失值失去类型，数据库无法阻止“满意度=苹果”或同一题重复写入两次。
更稳妥的选择有两类：
- 在
answer中设置value_text、value_number、value_date、value_boolean等列，用检查约束保证只有与问题类型匹配的一种值非空； - 按回答域拆成若干明细表，例如数值答案、文本答案和选择答案，共享答卷与问题版本标识。
前者查询集中、表较少，约束表达略复杂；后者类型清晰，跨类型汇总需要更多关联。项目规模不大时，两者都比无类型字符串更可控。开放文本可以保留原文并另建清洗或编码结果，不能让主题标签覆盖原始回答。
版本关系必须落在答卷上，不能只保留“当前问卷”
发布后的问卷版本应视为不可变对象。修正错别字、调整选项、改变跳转或翻译，都通过新版本或明确的版本内变更策略记录；答卷引用它实际展示的版本。查询历史答卷时，不应再关联项目当前的题目记录，否则旧答案会被新题文重新解释。
问题需要两个不同标识：一个稳定的概念或变量标识，用于说明跨版本“意图上属于同一测量”；一个问题版本标识，用于锁定当时的题文、回答域和逻辑。是否可合并由显式映射决定，不要因为稳定标识相同就自动拼接。参考期从7天改成30天、单选改多选、量表端点变化，都可能使数值不可直接比较。
DDI 的数据采集结构也把问题意图、问题文本、回答域、说明和缺失值分别描述，并让问题结构可版本化。这一思路能避免“题目文本没变，所以变量没变”的误判：显示条件或回答域变化，同样会改变数据含义。
矩阵、循环和重复测量需要“回答位置”
矩阵题的每一行可能共享量表，却测量不同对象；循环题会针对多个品牌、家庭成员或就诊经历重复同一问题；追踪研究又会让同一人跨波次回答。仅以 response_id + question_id 唯一约束，会让后一次值覆盖前一次。
答案主键中应能表示实例位置，例如 repeat_path、subject_instance_id 或独立的 response_item_instance。路径要引用稳定对象，不要只存屏幕上的“第2行”，因为随机顺序会改变位置。分析层再把“品牌A的购买意愿”透视成需要的列。
追踪研究还要区分参与者与答卷。participant_id 可以连接多个波次，response_id 只标识一次作答；若研究承诺匿名，就不应为了方便追踪而事后创造可识别关联。身份或联系方式如确有合法用途，应与研究答案分区存储，通过受控映射关联，并分别设置权限和保留期限。
把关键业务不变量交给数据库约束
应用代码会变，批量导入和人工修复也可能绕过某个页面校验。数据库至少应保护这些不变量：
- 每张表有稳定主键；外部提交标识在项目或批次范围内唯一，避免重试生成重复答卷；
- 答卷引用的问卷版本、答案引用的问题版本、选项引用的回答域必须真实存在；
- 同一答卷、问题版本和重复位置的单值答案只能有一条；
- 多选明细在同一答案下不能重复选择同一选项；
- 完成时间不能早于开始时间，数值在题目允许范围内，枚举状态只能取受控值；
- 删除问卷元数据时不能让历史答卷变成孤儿，通常应限制删除而采用归档状态。
PostgreSQL 当前文档对主键与外键约束的定义体现了这里的基本原则：主键唯一且非空地识别一行，外键要求引用值在目标表中存在，从而维护实体之间的参照完整性。数据库类型只是第一层，唯一、非空、检查和外键共同把研究规则变成可执行边界。
混合模型把采集事实与分析便利分开
推荐的数据流不是“永远用长表”，而是四个用途明确的层：
- 原始层：保留接收载荷、版本和时间，不做静默修改；
- 规范层：把答卷、问题、选项和重复实例解析成有类型、有约束的关系记录；
- 分析层：按指定代码本、样本和处理规则生成宽表或主题数据集；
- 交付层：图表与报告引用具体分析版本，而不是直接查询不断变化的业务库。
这让研究人员仍能使用熟悉的一行一答卷宽表，同时保留重新生成它所需的原始值和版本语义。需要快速上线的一次性调查可以只保存宽表与问卷快照；只要项目会重复、改版、多语言、跨系统合并或接受审计，混合模型的收益通常会迅速超过多几张表的成本。
从问卷派导出或通过允许的接口进入内部平台时，应一并保留项目、问卷版本、回收批次、稳定变量和原始选项标识，再映射到企业数据模型。问卷派中的分析宽表可以支持即时查看，内部仓库则负责长期关联时，不要用显示题文猜字段，也不要只传一份没有版本上下文的 Excel。
最后用最初的六条验收查询做实测。尤其要随机挑一份旧版多选或循环答卷，从数据库恢复当时页面和每个选择，再从规范答案生成分析列。若任何一步只能依靠原开发者口头说明，缺的不是更多存储空间，而是一段尚未进入模型的研究语义。