数据模型升级与查询兼容：字段变化不能只改名称

结构变化会进入每一次查询

数据库结构并非隐藏在后台的技术细节。一个字段从自由文本改成受控词表，会改变可搜索值；一个对象拆成两张表，会改变去重和统计方式。若团队只宣布新名称，没有说明语义变化，旧查询即使继续运行也可能回答不同问题。

版本说明应同时记录新增、废弃、重命名和关系变化，并给出迁移前后的示例。真正的兼容不只是程序没有报错，而是使用者知道结果是否仍然可以和旧版本比较。

映射必须允许不确定

历史资料经常无法精确落入新分类。强行把所有旧值映射到最接近的新词，会制造虚假的确定性。映射表应允许未知、部分匹配和需要人工复核，并保留原始值。

一对多和多对一关系尤其需要解释。对象合并后，历史统计可能需要重新聚合；对象拆分后，旧资料未必有足够信息完成分配。此时应明确边界，而不是自动复制一份到每个新类别。

发布迁移需要双重验收

技术验收确认程序能读取、写入和查询；内容验收则抽查代表性对象，比较迁移前后的数量、关系和解释。两者缺一不可。

迁移完成后仍要保留结构版本、脚本版本、执行时间和异常清单。研究结果引用的是当时的数据结构，未来复现时必须知道使用了哪一版Schema。

数据模型在实际项目中的检查重点

结构升级前应先盘点真实查询，而不是只看数据库表。某个字段可能没有出现在首页，却被自动报表、导出脚本或合作团队长期使用。迁移清单若忽略这些依赖，新版上线后才会出现数字突然变化、接口仍成功但含义已经不同的情况。

兼容层可以给使用者缓冲时间，但必须标注期限和转换规则。永久保留所有旧名称会让模型越来越难理解；立刻删除又会中断既有工作。较稳妥的做法是提供一段并行期，记录旧字段被哪些任务调用，再有依据地结束支持。

抽样验收应选择不同关系复杂度的对象，包括没有关联、只有一个关联以及跨越多个来源的对象。只比较总行数无法发现连接关系被重复或丢失。对于关键统计，还应保存迁移前后的查询文本和结果摘要。

面向普通使用者的版本说明不必展示全部数据库语法，但应明确哪些页面、筛选器和导出字段发生变化。开发者文档再补充结构差异、迁移脚本与接口示例，两层说明共同维持可理解性。