山西网站开发旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f809efc6cf91.html
📄
山西网站开发旧系统字段无法完整迁入时怎样决定保留项
先按“字段是否仍驱动当前业务”分两类处理：仍被前台展示、后台查询或对外接口依赖的字段优先保留并补全；只用于历史记录、不再参与任何流程的字段可以冻结归档。缺少完整数据或权限时，最小动作是导出一份字段清单，标注每个字段的最后使用位置和最近一次有值的时间，再据此决定迁移、归档还是放弃，而不是先动手改表。
条件一：字段仍被业务使用，但数据不全
这类字段不能因为缺值就删。判断依据是它是否出现在当前的表单、列表页、筛选条件或对外输出中。只要有一处还在用，就应保留结构，把缺失值标记为待补，而不是让新系统直接少一列。
可执行的动作是先做一次字段映射表：旧字段名、新字段名、类型、是否必填、缺失时的默认值。迁移时对缺失值写入明确的占位，例如空字符串或约定的未知标记，并在后台加一个待补清单。这样做的结果是新系统上线后不会因为缺字段而报错，后续补录也有入口。能推出的结论只是结构可用，不能推出数据已经完整。
条件二：字段只服务历史查询，不再进入业务流程
如果该字段只在旧后台的详情页出现，既不参与计算，也不出现在任何对外接口，可以考虑不迁入主表，改为只读归档。判断依据是：过去一个业务周期内没有新增写入，也没有下游系统读取。
动作上，把这类字段连同主键导出为独立的归档表或文件，主库只保留必要索引。结果是新系统结构更轻，查询路径更短。但要注意例外：如果未来可能出现审计、对账或客户追溯需求，归档必须保留可关联的主键，否则以后无法还原。此时不能因为当前没人查就断定永远不需要。
缺少权限时先做只读盘点
没有改表或导出权限，仍然可以做字段盘点。让有权限的人提供字段列表、样例数据和最近更新时间，或者只申请只读账号查看结构。最小动作是产出三列信息：字段名、当前用途、缺失程度。
这份盘点能支持的决定是排序，而不是最终迁移。它能告诉你哪些字段必须先谈权限，哪些可以先归档。不能从“拿不到数据”推出“字段不重要”，也不能从“字段为空”推出“业务没用过它”。空值可能来自采集缺失、权限过滤或历史清理，需要分别确认。
用一个假设例子说明取舍
假设旧系统有一个“客户来源备注”字段，前台不再展示，但销售在导出报表时会看。迁移时该字段有部分记录为空。此时应保留字段并允许为空，同时在导出逻辑里保留该列。若直接删除，销售报表会少一列，后续无法区分来源；若强行设为必填，又会卡住没有备注的旧数据写入。保留可空字段是同时满足两边的做法。
决定保留项后的下一步
确定保留清单后，先在新系统建结构并跑一次只读比对：旧系统有值的记录数、新系统成功写入的记录数、缺失记录的主键范围。比对结果决定下一步是继续补数据，还是先处理映射错误。若比对差异集中在某几个字段，说明问题在映射规则而非数据本身；若差异分散，则更可能是权限或导出范围不完整。这个判断只针对本次迁移，不能当作长期数据质量的结论。
