迁移字段映射怎么做

字段名一样为什么还需要业务解释？

数据库列名通常只能提供线索，不能完整说明业务含义。“金额”可能是商品原价、订单应付、实际到账或结算净额；“状态”也可能对应审批、付款或履约的不同阶段。迁移前应拿历史业务样本与源系统说明核对，先形成定义，再选择目标落点。

某些旧字段只在特定期间或配置下使用。若直接把当前页面的解释套到全部历史数据，就会忽略规则变化。映射记录应包含适用范围、资料版本和解释岗位，注明哪些时期需要不同转换。无法确认的字段暂时隔离，不能为了填满目标表而随意赋予含义。

源系统的业务负责人应参与说明，但口头解释还需留下可复查材料。可以记录对应页面、接口说明、导出规则或经授权的脱敏业务单。这样当另一批数据出现不同情况时，团队能回到依据判断，是规则遗漏还是源资料异常，而不必从头猜测。

空值、默认值和未知值如何区分？

空字符串、数据库空值、旧系统默认码和用户确实没有填写，可能是不同状态。目标系统有必填要求时，不宜统一补成某个看似有效的值。默认值应经过业务批准，并说明它会如何影响查询、下单、通知或统计。

例如未知地址资料不能通过虚构地区补齐；未知会员等级也不能自动被赋予某个权益。可以保留原始资料引用和异常类别，将不能直接转成有效对象的记录进入处理队列。是否允许迁入为受限状态，应依据目标系统实际业务规则核对，而不是仅为了让导入程序成功。

枚举映射同样需要覆盖历史废弃值。把无法识别的状态全部转成“完成”，可能让原来的待处理订单消失。映射表应记录每个源值的业务含义、目标表达、是否需要后续动作，以及无法判断时由谁批准。导入结果报告要公开这些隔离与排除项。

金额、数量和时间怎么转换？

金额以元为单位、使用精确十进制和接口字符串；积分、会员折扣与数量退款各有计算器，退款从冻结成交金额按累计数量差额分配。

迁移时需要先判断源金额采用何种单位、税口径与精度，再转换为目标约定。不要根据字段长度推断“元”或“分”，也不要用二进制浮点计算资金结果。转换应有明确舍入点，并能够用相同输入重复得到相同输出；规则更新后应保留旧版本，解释此前批次。

数量可能包含包装或计量单位。商城销售数量和仓库物料数量不一致时，需要提供换算是否适用于历史规格，不能拿当前包装规则覆盖过去成交。退款数量、赠品数量和退货入库数量也未必相同，应分别保存业务含义。

时间字段要说明是业务发生时间、数据库写入时间还是导出时间，以及是否带时区。不能只把字符串格式改漂亮，而失去原时间意义。跨日分组、订单排序和财务截止可能受到转换影响；应选边界样本核对，并记录对无法解释时间的处理规则。

内部编号变化后怎样保住关联？

为来源系统、业务范围和原编号建立稳定关联，再保存目标内部编号。会员、商品规格、订单行、退款和包裹等对象有自己的关联关系，不能把同名字段当成同一种编号。新的内部主键产生后，所有引用都应按同一映射恢复。

映射本身也需要约束。相同来源对象多次运行时，不应生成多个目标对象；不同范围的相同原编号不能被错误合并。原编号若包含前导零或大小写差异，应按已确认规则保存，不能为了方便转成整数而丢失意义。

对象不存在时应有明确处理。例如订单引用的商品已被旧系统删除，可以保留历史快照，但是否建立只读历史对象需设计；不能随意关联到名称相同的新商品。映射应保留异常理由与最终批准决定，避免后续售后查询再次猜测归属。

转换规则怎样支持预演与重复运行？

建议为规则和输入批次分别编号，记录源资料校验值、适用范围、转换版本、运行时间和目标环境。重跑同一批次时，应能判断哪些对象已经处理，哪些失败待修；不能依靠“先把目标表清空”实现重复运行，因为目标可能已有新业务。

结构迁移与业务数据导入应分开。前者调整应用所需结构，后者解释并转移旧业务对象，两者的责任和回退条件不同。迁移资源归所属业务域，包含 SQL 与 Java Flyway 迁移；已发布迁移字节及 Java identity/checksum 需要保留，运行与迁移角色分开。 不能把修改已有结构迁移脚本当成修复某个导入字段的常规方法。

规则修订后，先圈定受影响对象，保存修订前后的差异，再决定重新导入还是执行受控更正。若历史对象已有售后或外部账务动作，直接覆盖可能破坏正在运行的关联。预演应验证这些路径，而不是只确认数据库能接收一批行。

一份字段映射证据应该包含哪些列？

下表提供审查角度，具体记录可使用公开模板，不是目标数据库的真实表结构。

映射要素	应填写的依据	必须审查的风险
对象与来源	来源系统、组织范围、原编号、资料版本	跨范围混用或同名对象错误合并
字段解释	业务含义、适用期间、责任岗位	用当前规则解释全部历史
类型与转换	单位、精度、时区、枚举及规则版本	资金舍入、时间偏移、未知状态失真
空值与异常	缺失原因、隔离条件、批准或排除决定	静默补默认值掩盖不可用资料
目标关联	内部编号、外部引用、依赖顺序	订单、售后和附件失去归属
核验方法	分组统计、脱敏样本、源目标查询位置	总数相等但业务错配

审查时先选择能揭示规则边界的样本，而不只随机挑选几行正常资料。包括废弃枚举、缺关联、不同单位、跨日时间、重复编号与历史对象变更。每个样本要能指出原资料引用、转换结果和业务判断，避免程序输出一行“成功”就结束检查。

怎样解释数量一致但结果仍然错误？

全局总数容易掩盖范围错配。一个商城少迁入会员，另一个商城多迁入同样数量，总数仍然相同。应按来源范围、状态和业务日期分组，并分别计算纳入、排除、成功与隔离的集合。金额也应按相同交易口径核对，不能把不同含义相加后比较。

差异报告要说明是预期转换、源资料问题、程序缺陷还是尚未确认。得到业务批准的排除应带范围和理由，不宜只放在开发者聊天记录里。修复后回到相同统计方法复验，才能判断问题是否关闭；换一个查询口径得出一致，并不能证明原差异已消失。

字段映射可从迁移字段映射与对账模板开始，整体执行顺序见迁移专题。通过迁移沟通服务讨论目标模型与资料条件，并按数据库迁移文档区分源码结构升级和历史数据转换。