随州网站制作：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6d36df97a282.html
📄
随州网站制作：旧系统字段无法完整迁入时怎样决定保留项
先判断字段在业务上是否仍被使用，再判断它在旧系统里是否真的存有可用数据，两项都成立才进入保留清单；只满足一项的字段应改写、合并或退出。迁移工具报错、目标库字段上限、编码不兼容，都只是执行层信号，不能替代这条业务判断。
保留、改写、退出的分界条件
把字段逐个归入三类，依据不是“旧系统有就搬”，而是数据来源和下游用途是否同时存在。
- 保留：字段仍被表单、列表或对外展示直接读取，且旧库中该列有非空值。这类字段应原样映射，最多调整类型长度。
- 改写：业务上还需要，但旧数据只以拼接文本、备注或附件形式存在。此时先定义新结构，再写解析规则，不能直接把整段文本塞进一个长文本列。
- 退出：字段已无任何页面、接口或报表引用，或旧库中该列长期为空。退出不是删除历史，而是不再进入新模型，旧库保留只读快照即可。
如果某字段业务上仍被引用，但旧库中大量为空，它应归入改写而非保留：需要先确认空值是“从未采集”还是“采集后未回填”，两者的处理方式不同。
先做一次字段使用盘点，而不是先跑迁移脚本
迁移报错往往出现在执行阶段，但决定保留项的信息在业务侧。可先做一份字段清单，至少记录四项：字段名、当前读取位置、旧库非空比例、是否参与对外展示或结算类逻辑。
假设某随州本地企业的旧站有一个“客户备注”字段，里面混写了联系人、地址和跟进时间。直接保留这一列，新系统仍然无法按地址筛选；直接退出，又会丢掉跟进时间。合理做法是把它改写为三个独立字段，并接受解析后部分记录缺失。这个例子只用于说明比较方法，实际比例应以本地数据为准。
盘点完成后，把“读取位置”为空且“非空比例”极低的字段优先列入退出候选，再对剩余字段逐一确认。这样做的结果是：迁移脚本要处理的字段数下降，报错范围收窄，后续排查不再被无关列干扰。
无法完整迁入时，先固定不可丢失项
当目标结构装不下全部旧字段时，不要平均分配精力，而要先锁定不可丢失项。判断标准是：丢失后是否会导致业务无法继续，例如订单关联标识、对外展示的主体信息、后续对账需要的编号。
不可丢失项确定后，其余字段按“可重建”和“可放弃”再分一次。可重建指能从其他字段或旧库快照重新推导；可放弃指业务上已不再依赖。这个顺序会影响下一步：如果不可丢失项本身也存在空值或格式冲突，迁移就不能整体推进，而应先做局部清洗和试迁。
需要说明的是，旧库中某列查询结果为空，只能说明当前快照没有值，不能单独证明该字段历史上从未使用。还要看旧系统的写入逻辑、备份版本和是否存在其他存储位置，否则容易误判为可退出。
改写字段时的取舍：保留原值还是只保留解析结果
改写适合业务仍需要、但旧结构不合理的字段。此时有两个成立条件不同的选择：
- 保留原值加解析结果：适用于原文本可能包含无法自动识别的信息，且后续仍需人工回查。代价是新库多一列原文，存储和展示都要额外处理。
- 只保留解析结果：适用于原文本格式稳定、解析规则可覆盖绝大多数记录。代价是解析失败的部分会丢失上下文，需要提前确认失败记录如何留档。
选择依据是解析失败后的补救成本。如果失败记录可以直接联系客户补齐，只保留解析结果可行；如果失败记录无法回溯，保留原值更稳妥。这个判断与使用哪种建站程序无关，换系统也不会改变。
退出字段前要确认的三件事
退出是最容易被低估的一步。执行前应确认：
- 没有页面模板、接口或定时任务仍在读取该字段；
- 旧库快照已可独立恢复，不依赖新系统；
- 相关报表或对外文件不再引用该列名。
三项都确认后，退出字段可以从新模型中移除，但旧库只读保留。若其中一项无法确认，应暂缓退出，改为在新库中保留占位列，等确认完成后再清理。这个动作的直接结果是：迁移范围缩小，同时避免上线后因某个隐藏引用导致页面报错。
字段保留项定下来之后，下一步才是确定映射规则和试迁范围；如果保留清单本身还在变动，试迁结果不具备参考价值。
