通化网站制作：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f59943a61176.html
📄
通化网站制作：旧系统字段无法完整迁入时怎样决定保留项
先给结论：不要按“字段能不能迁”决定保留，而要按“这个字段在当前业务里是否仍被读取、被谁读取、缺失后会造成什么后果”决定。把每个字段标成保留、合并、转附件、只读归档或删除五类，再对保留项做一次最小可用验证，迁移才算可控。
先给字段做一次用途盘点，而不是先看数据库
旧系统字段无法完整迁入，通常不是技术容量问题，而是新旧模型对同一件事的定义已经不同。比如旧站的产品表里可能有“规格一、规格二、规格三”三个字段，新模型改成了结构化参数；字段名还在，含义已经变了。
盘点时以读者手里的一个页面或一张资料表为对象，逐字段回答三个问题：
- 这个字段现在还有没有人看？前台展示、后台查询、客服引用、对账核对，分别算不同用途。
- 它是否被别的字段或流程依赖？例如“区域”字段可能被运费计算或门店筛选引用。
- 缺失后最坏结果是什么？是页面少一行说明，还是历史订单无法核对、客户无法被联系。
把答案写在同一张表里，字段名、当前用途、依赖方、缺失后果四列即可。这一步的产出不是结论，而是后面分类的依据。
用五个处理类别替代“保留或不保留”的二选一
很多迁移争议来自只有两个选项。实际可执行的分类至少有五种：
- 保留：当前仍在用，且新模型有对应位置，直接映射。
- 合并：多个旧字段表达同一件事，合成一个新字段，但要记录合并规则。
- 转附件：结构上不再需要，但内容有查阅价值，转成图片、PDF或备注文本随记录保存。
- 只读归档：不再参与前台展示和业务计算，只在新系统里留一个只读入口供追溯。
- 删除：确认无用途、无依赖、无合规留存要求，且已备份。
分类的关键是让“转附件”和“只读归档”成为真实可选项。它们能吸收大量既不该丢、也不该继续参与业务计算的字段，减少非此即彼的争论。
判断保留项的三个可区分证据
决定某个字段是否进入“保留”，可以看三类证据，它们指向不同结论：
- 有活跃读取：最近一段时间的后台查询、导出记录或页面展示中确实出现该字段。这是保留的强证据。
- 有下游依赖：该字段参与筛选、计算、通知或对外接口。即使没人主动看，也要保留或做等价替代。
- 只有历史留存价值：查不到活跃读取，也没有下游依赖，但内容本身记录了当时的业务事实。这类更适合只读归档或转附件，而不是塞进主表。
反过来，如果某字段既无读取、又无依赖、内容也能由其他字段推导出来，删除才是合理选择。注意：导出量或查询量短期归零，不能单独证明字段无用，也可能是统计口径变化、入口被下线或使用习惯转移造成的，需要结合访谈和依赖检查再判断。
一个假设例子：把“旧客户备注”拆成三种处理
假设旧系统客户表里有一个长文本字段“备注”，里面混着三类内容：联系方式补充、历史沟通记录、内部标记。新系统没有等长文本字段。可按下面方式处理：
- 联系方式补充：合并进新的联系信息字段，并保留原文出处。
- 历史沟通记录：转为附件或独立记录，标注时间和来源系统。
- 内部标记：确认是否仍被筛选或提醒流程引用，若是则保留为枚举字段，否则只读归档。
这个例子的意义在于：同一个字段可以拆开处理，不必整体保留或整体丢弃。假设迁移前先做一次抽样，人工核对若干条记录在新旧系统中的呈现是否一致，再决定是否扩大迁移范围。抽样结果若发现合并规则误判，下一步应先修正规则，而不是继续批量导入。
动作与结果：先迁一批，再决定全量
确定分类后，实际动作是选一个字段数量适中、业务影响可控的批次先迁。迁移后做两件事：一是核对保留项在新系统中的展示和调用是否正常；二是确认归档项仍可被检索到。
如果验证通过，下一步是固化映射规则并扩大范围；如果发现某类字段频繁需要人工修补，说明分类或映射规则本身需要调整，此时应暂停扩大，先回到盘点表修改规则。这个顺序能避免把错误规则复制到全部数据上。
最后，保留项清单要写成可交接的文档：字段名、处理类别、映射规则、验证结果、负责人。旧系统退出后，这份文档就是判断“某个信息为什么不在新系统里”的唯一依据。
