数据存明细还是只存汇总，看半年后有没有人追问到更细一层

只存汇总，半年后有人问"6 月 12 号那笔为什么没算进来"，谁也答不上来。存明细就答得上，代价是存储和查询的速度。

分岔点是半年后会不会有人追问到更细一层

这个分岔点的关键是"追到多细"。追到日、追到站点、追到品类，汇总表都答得上。追到某一单为什么被排除在外，汇总表答不上。

还有一个更硬的条件：排除规则有没有写下来。没写下来，存了明细也答不上来——你只知道这笔不在汇总里，不知道它为什么被剔除。所以这条分岔点实际上是两个条件叠在一起：会不会追问，以及追问的东西当时有没有留下来。

半年后会不会有人追问到更细一层，决定留不留明细

两条路摆在这张表里

存明细买的是可回溯。只存汇总买的是轻。这两条路的差别在半年后才显形。

选错的代价差在哪

A 路选错的代价是慢和贵。18 万行的明细表压到 4.2 G 三年，单看存储不算什么，麻烦在每次聚合要多跑 15 分钟。这 15 分钟是每天都要付的，付一年就是九十个小时。

B 路选错的代价是不可逆。我们有过一次，客户对账的时候问某个月某一周的退货为什么比上个月多，那一周的排除规则是当时口头定的一个例外，只在群消息里说过。那条消息后来被清了，规则也没人记得。那一周的数字永远查不出来了。

退回来要花多少

存明细转汇总，把三个月前的明细删掉就行，成本几乎为零。这一步之所以敢做，是因为明细转汇总的方向是安全的。

只存汇总转明细，从今天起开始存就行，过去的回不来。所以这条路没有回退，退成本最低的时间窗是"从现在起存"——任何一天开始存都不晚，晚的只是历史。

这也是两条路最容易搞混的地方：明细转汇总可以随时做，汇总转明细只能在过去和未来之间选。

优劣在什么条件下翻转

存储单价会翻转优劣。存储便宜到可以忽略，存明细赢，宁可多花磁盘也别丢历史。存储贵而且明细字段多到查不动，只存汇总赢。

另一条是数据量本身。每天三百万行和每天三百行是两种问题，前者明细是负担，后者明细几乎是白送。

两条都不该走的情况

三条同时命中，两条都别选：确定一年后没人再查、明细含敏感字段、存储预算已经被别的东西占满。这三条凑齐，先想清楚这个数还要不要留，而不是选怎么存。

我自己的做法是留一份中间层：每天三百行汇总留着给人看，明细只留九十天。但有一条我后来加了，凡是会触发赔付的品类，明细留三年。少存的那部分数据省下的不是钱，是将来要花两天时间解释的麻烦。