CSV 对账、关联与透视:先核对记录,再生成报表
用订单导出示例比较按主键对账、查找关联和数据透视,检查重复键、空值与汇总口径,再安全应用 JSON 配置补丁。
例子:核对两次订单导出
库存团队每周收到新的商品导出。上周 001 属于设计组,本周改为运营组,同时整份表格的顺序也变了。逐行文本对比会产生很多无关差异。真正需要回答的是:主键 001 的哪一列发生变化,以及是否有商品新增或删除。
主键和空值先约定清楚
先写清楚主键约定:一键对应一条记录、跨批次保持稳定、表示形式一致。即使电子表格看起来相似,把 001 转成数字 1 也破坏了约定。空键和重复键需要有意识地处理,不能让工具随意选择某一条匹配记录。
先对账,再关联和汇总
先按主键对账,再关联查找表。较小的 UTF-8 CSV 可分别检查新增、删除、变化单元格与列名差异,并下载完整 JSON 和有内容的 CSV 报告。Neatbo 每侧限 1 MiB,更大的表格需其他流程。CSV 导出会防护公式式值,JSON 则保留原字符串供核查。确认变更后,如果所有原商品都必须可见,应采用左连接;内连接会有意丢弃未匹配商品,适合交集报表,却不适合未经说明的完整库存报表。
001,Ada → 001,Ada Lovelace 是同一记录的变化,不应算作删除加新增;只改变行顺序的表格不应出现单元格变化。交付报表前保留核对依据
之后再做透视。此工具每次只处理一个行维度和一种指标,计数与求和应分别运行。求和前先核对记录数,抽查一个无匹配分组,区分真实的零和没有记录的组合。按部门拆分交付时提供 ZIP 与其中的清单;每份 CSV 保留表头,清单连接编号文件名、原始分组值与行数。最终审阅者应能追踪一条记录经过对账、关联和汇总的过程,而不需要猜测。
| 不能单凭 | 应该补查 |
|---|---|
| 行数相同 | 主键集合及每个字段仍可能不同 |
| 关联成功 | 查找键必须唯一,并核对未匹配记录 |
| 汇总数值相同 | 确认分组口径、空组合和浮点精度 |
- 把编号作为字符串,检查前导零是否保留。
- 对新增、删除、修改分别抽样,再核对分组总数。
- 配置补丁先写test条件,失败时不要使用半成品。
将语法迁移与数据合同分别核对
例如设备配置与订单表一起交付:INI 中 Windows 路径是字面文本,本地化 Java Properties 消息却使用反斜杠转义。都按普通 key=value 处理,可能使生成的 JSON 虽然语法有效,消息内容却已改变。应选择正确语法、保留字符串,并在接收应用里检查样例。
静态 HTML 导出转 CSV 更便于交付,但提取单元格不代表满足导入合同。选好表格后,明确必填字段、允许取值与数值边界;可选空值和缺失必填值并不相同。保留异常记录,利用物理行号定位跨行单元格,不把未校验列视为已批准的数据。
区分存储声明、保真字节与确认后的模式
本地迁移可能包含多份独立合同:定长码点字段、缓存新鲜度未确认的工作簿公式,以及类型尚未确认的 CSV 列。逐项明确提取,保留原文件,将建议与已批准导入规则分开。
配套文件先替换指定 JSON 值并检查可见键名,按精确坐标和换行应用补丁,保留 Frontmatter 正文哈希。EditorConfig 和 npm 锁报告只解释提供的声明,不能等同于编辑器行为、已安装依赖或可执行数据库迁移。
参考资料
- CSV 与 JSON 数据核对流程
相关格式和处理规则的参考。
- 开发数据检查与补丁应用
相关格式和处理规则的参考。