青海网站建设旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a4a678fd783b.html
📄
青海网站建设旧系统字段无法完整迁入时怎样决定保留项
先给结论：字段能不能保留，不取决于它在旧系统里用了多少年，而取决于它在新系统里有没有明确的承接位置、输入来源和消费方。三者缺一，就应进入合并或归档，而不是硬塞进新结构。下面用一个假设情境把决策过程走一遍。
假设情境：三百条样本通过，全量导入却报错
假设某青海本地企业的旧站运行多年，产品参数存在自定义字段里。迁移前抽样三百条记录试导，全部成功，团队据此认为字段可以整体保留。全量导入时却出现大量空值和截断，原因是旧字段允许自由填写，有人写“约两米”，有人写“2m”，还有人留空；而新系统的对应字段是数值加单位。样本里恰好都是规范写法，所以没暴露问题。
这个反常现象说明：抽样成功只能证明样本本身干净，不能证明字段定义稳定。判断保留项之前，要先看字段的取值分布，而不是看样本通过率。
先给每个旧字段找三个归属：输入、承接、消费
把旧字段逐个过一遍，对每个字段问三个问题：
- 输入来源：这个值由谁填写，是人工录入、系统生成，还是历史导入？如果来源已经消失，字段就是死数据。
- 承接位置：新系统里有没有语义相同的字段或结构？没有对应位置时，是新建字段、并入备注，还是放进附件？
- 消费方：谁在读这个值？是前台展示、筛选条件、内部报表，还是没人用？没有消费方的字段，保留只是搬运成本。
三个问题都能答上的字段，进入保留清单；只答上输入来源的，进入归档清单；三个都答不上的，直接丢弃。这一步不需要写代码，用表格逐行标注即可，但它决定了后面迁移脚本要写多少分支。
用一组可区分的证据决定保留、合并还是归档
光靠印象容易把“看起来重要”的字段留下。可以用下面这组证据来区分：
- 统计该字段的非空率。非空率很低，且空值集中在近两年的记录里，通常说明填写流程已经废弃，倾向归档。
- 看取值是否可枚举。取值能收敛到有限几种写法的，倾向合并到新字段并做映射；取值高度自由、长短不一的，倾向保留为文本或附件。
- 查前台是否引用。如果模板里已经没有任何位置输出这个字段，保留它的理由只剩历史查询，那就放进归档而不是主表。
- 确认是否参与筛选或排序。参与筛选的字段对格式一致性要求最高，格式混乱时优先考虑重建，而不是原样迁入。
这里要注意一个边界：非空率高不等于必须保留。如果高非空率来自默认值自动填充，字段本身没有区分度，保留它反而会污染新系统的筛选结果。反过来，非空率低也不等于可以删，某些字段只在特定品类下填写，低频但关键。
一个注明假设的短例子：把“约两米”变成可迁移的值
假设旧字段“长度”里混有三种写法：纯数字、数字加单位、文字描述。处理方式可以分三层：
- 能解析成数值的，写入新系统的数值字段，单位统一为米。
- 不能解析但语义明确的，例如“约两米”，人工确认后写入数值字段，同时在备注里保留原文。
- 完全无法判断的，原文整段迁入备注或附件，不占用结构化字段。
动作的结果是：新系统的数值字段保持干净，可以参与筛选和排序；原始表述也没有丢失，需要时仍能查回。这个结果会直接影响下一步——如果备注类字段数量很大，就要考虑给它单独的存储和检索方式，而不是继续堆在主表里。
规模化后出现例外时，把决策规则写下来再执行
个别样本成立、规模化后出现例外，是旧系统迁移的常态。应对方式不是逐条救火，而是把上面的判断固化成规则：什么条件下保留、什么条件下合并、什么条件下归档，各自由谁确认。规则写清楚之后，迁移脚本的异常分支才有依据，人工复核也只需要处理规则覆盖不到的部分。
最后提醒一点：字段保留项定下来之后，旧系统的读取权限不要立刻关闭。留一段并行期，用实际查询验证新结构是否够用，再决定是否彻底下线旧表。这一步的取舍标准是查询是否还能被满足，而不是迁移进度是否好看。
