茂名网站制作：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /73af3aaaa76b.html
📄
茂名网站制作：旧系统字段无法完整迁入时怎样决定保留项
先给结论：字段能不能保留，不取决于它在新系统里有没有对应位置，而取决于它是否仍参与当前业务判断。如果某个字段只服务已经停用的流程，直接舍弃；如果它仍被查询、导出或对账使用，就要保留，并接受它可能以文本备注、独立附表或自定义字段的形式存在，而不是硬塞进主表。茂名网站制作项目里常见的困难，是旧系统字段数量多、命名混乱，个别样本看起来都能迁，真正批量导出后才发现大量空值、重复语义和互相矛盾的内容。
先区分两类字段，再谈保留清单
把旧字段分成两类，判断标准完全不同。第一类是业务字段，例如合同编号、办理状态、所属区域、负责人；它们影响查询、统计和权限，必须优先保留。第二类是描述字段，例如旧版备注、临时说明、历史操作记录；它们只在少数场景被人工翻看，适合降级保存。
判断一个字段属于哪一类，可以问三个问题：最近一个业务周期内是否有人按它筛选；是否有报表或导出依赖它；删除后是否还能从其他字段推导出同样信息。三个问题都答否，基本可以舍弃。只要有一个答是，就进入保留候选，再决定以什么形式保留。
个别样本成立、规模化后失效时怎么取舍
抽取少量旧记录试迁时，字段往往显得干净完整，这是因为样本通常来自活跃数据。批量导出后会出现三种例外，处理方式不同。
- 空值比例高：如果某字段在多数记录中为空，只在少数旧记录里有值，不要为它建独立结构，改为并入备注字段，保留原文即可。
- 语义重复：两个字段表达同一含义但取值格式不同，先确定一个主字段，另一个作为来源说明保留，避免新系统出现两个可编辑入口。
- 取值冲突：同一记录在两个字段里给出矛盾内容，不要自动合并，保留两者并标注来源，交给业务人员判断。
这里有一个假设例子。假设旧系统同时存在“状态”和“处理结果”两个字段，抽样一百条时两者基本一致，看起来可以只留一个。批量导出后如果发现约三成记录中“处理结果”为空而“状态”有值，就说明前者并非必填，不能作为主字段。此时应保留“状态”作为新系统的业务字段，“处理结果”转为备注来源，而不是把两者强行映射成同一个下拉选项。这个判断依据的是空值分布，不是字段名称是否好听。
保留项以什么形式落地
保留不等于原样搬进主表。常见做法有三种，选择依据是使用频率和维护成本。
- 主表字段：需要被筛选、排序、参与权限控制的字段，放进主结构，并明确必填与选填。
- 附表或明细：一对多关系的历史记录，例如多次变更日志，放进独立明细，避免主表膨胀。
- 文本快照：低频查看的旧说明，合并成一个只读文本块，保留原始标签和值，不参与查询。
实施时的实际动作是：先导出全部旧字段的取值分布，包括空值比例、唯一值数量和最长内容长度；再按上面的规则给每个字段标注去留和落地形式；最后用一批真实旧记录做一次试迁，核对保留项是否还能支撑原有查询。试迁结果会直接影响下一步——如果发现某个被降级为文本的字段其实经常被筛选，就应把它重新提升为主表字段，而不是等到上线后再补。
哪些边界不能照搬
上述方法适用于字段数量可控、业务规则相对稳定的旧系统。如果旧系统本身仍在运行、新旧两边需要并行一段时间，就不能按“一次性迁移”处理，保留项要同时满足两边读写，成本会明显上升。如果字段涉及对外承诺、资质信息或需要长期留痕的内容，即使使用频率低，也不应仅凭空值比例删除，而应保留只读快照并说明来源。
另外，个别样本成立不等于整体成立。抽样时尽量覆盖不同时间段和不同业务类型，而不是只取最近记录。批量导出后如果发现某字段取值几乎全部相同，也要区分是业务本身单一，还是旧系统录入时被默认值覆盖；前者可以舍弃，后者需要保留原始来源以便追溯。把这些条件写进迁移说明，后续维护的人才知道某个字段为什么留下、为什么没有界面入口。
