先给结论:如果导出文件还能打开但字段看不懂,优先做“字段字典”而不是重装旧工具;如果文件已经打不开,只能从残留的界面截图、同期文档和数据库结构反推字段含义,并且必须标明哪些是推断、哪些有原始依据。百度快照作用在这类迁移里,主要是充当一份带时间标记的旁证:它可能保留过旧页面的字段名、栏目标题或说明文字,但它本身不是权威数据源,不能单独用来确认字段的准确口径。
这种情况最省事,也最值得先做。旧系统导出常见的是 id、kw、ctime、stat 这类字段,单看名字无法判断 stat 是状态还是统计值。此时不要急着把整张表导入新系统,先做一份字段字典,把每个字段对应的中文名、取值样例、可能的单位、是否允许为空写清楚。
具体动作:把导出文件的前若干行另存为一份“样例表”,对每个字段手工填写三列——原字段名、推断含义、判断依据。判断依据可以写“旧页面表头”“同期需求文档”“同一字段在其他表里的取值分布”。做完这一步,再决定哪些字段进入新系统、哪些直接丢弃。这样做的结果会直接影响下一步:有依据的字段可以放心映射,只有推断的字段要先标记为待确认,避免把旧数据带进新口径。
百度快照在这个环节的价值是补充界面证据。假设某个旧后台页面曾被快照保存过,快照里可能还留着表头文字或字段说明,这比单看拼音字段名可靠。但要注意两点:一是快照可能只保存了页面的一部分,字段说明未必完整;二是快照的时间点未必和导出文件的时间点一致,中间可能已经改过字段含义。因此快照只能作为交叉验证的一条线索,不能作为唯一依据。
这时问题从“翻译字段”变成“重建字段”。可行的顺序是先找结构、再找语义、最后找时间线。
百度快照作用在这个条件下的定位更窄:它只能提供某个时间点上页面呈现过的文字,不能证明字段在数据库里的真实定义。如果快照里的表头和你从代码里恢复的字段顺序对不上,要以代码和数据库结构为准,快照只作为命名参考。
不是所有旧字段都值得花力气还原。可以用两个条件来筛:
这个分界会改变你的动作:已确认字段可以直接映射进新结构;待确认字段建议以原始名保留,并附上推断说明;仅存档字段不要进入新系统的核心表,放到冷数据区即可。这样做的好处是,将来有人质疑旧数据时,你能说清楚每个字段的可信级别,而不是笼统地说“这是旧系统导出的”。
假设某旧系统导出的文件里有一个字段叫 flag,取值只有 0 和 1。同期文档里提到“是否有效”,旧代码里这个字段被用在筛选条件中,而百度快照保存的旧页面表头写的是“状态”。三个来源都指向“有效性标记”,那么可以把它确认为布尔型状态字段,映射到新系统的“是否有效”。如果只有快照写着“状态”,而代码里这个字段同时参与排序,那就不能急着定为布尔值,需要先确认它是否其实是数值型优先级。这个例子的重点不是结论,而是判断方法:来源越多、越独立,字段含义越可靠。
无论走哪条路径,最后都应该产出一份字段对照表,包含原字段名、确认含义、依据来源、可信级别、处理方式。这份表是迁移和复查的入口,也是将来解释旧数据的依据。
例外情况有三种:一是旧字段本身是加密或编码过的,还原含义没有意义,只需要保留原始值和解码方式;二是字段涉及个人信息或敏感数据,即使能还原也不应长期保留,应按合规要求处理;三是旧合作关系已经退出,但对方仍可能引用旧字段,这时要保留一份只读的字段说明,避免双方对同一字段的理解继续分叉。
百度快照作用在这里的边界很清楚:它能帮你找回一部分旧页面的文字线索,但不能替代数据库结构、代码和同期文档。把它当作一条旁证,而不是答案本身,旧字段的保存和迁移才不会建立在猜测上。