凭什么，CTO 给我这个 SQL 老 Boy 涨了 1万工资？

多年前，我去面试一家法资化妆品公司。

到点一看，惊呆！四面厂房，高鼻子烟囱，久违的制造业气息，兜兜转转又回来了。

怎么回事？不是说好了，是电商么，怎么搞的跟电子厂一样。

正在驱赶脑袋里无数问号时，我被带到一个称作面试的地方。全黄色系餐厅，餐桌一码的齐，糕点，咖啡，果汁，三三两两的小姑娘，各个精致玲珑。

原来，内有乾坤。

HR带着笑过来，请咖啡师做了两杯拿铁，一边介绍厂子，一边旁敲侧击我对这份工作的期待。

这么多年了，HR的这点小心思，我熟门熟路。面子是给要给足人家的，问题要害也要谈到。总体来说，相谈甚欢。接下来就去见 Tech Leader 还有 CTO.

技术问，其实不必说了。MES, ERP, MRP, 信息管理软件开发，理论都相通，架构也稳得坚如泰山。

唯一，让我有发挥，能表现自己的，是这么件事。CTO谈到，我平时怎么解决难题时，我谈到了看书。

看CTO眼神略带期待，我知道有表演的机会。

平时写SQL,写J2EE，上手无非就是多做项目。但能够脱离项目，研究问题内核，这就看个人兴趣所向了。师傅带你入门可以，但精深，走得比师傅老人家更远，得看自身。

多年的CRUD项目，让我受教最深的，是数据建模。其他技术类障碍，只要有“科学有险阻，苦战能过关”的勇气，早晚都能解决。

唯有数据建模，曾让我一度相信，情商在真正的高智商面前，不值一提。

有些人设计的数据结构，就是比其他人，比如曾经那么笨的我，要好上千倍，万倍。

我去看，数据结构与算法，设计模式，常常很受打击。拼命记住了那些常用的数据结构与算法，那23个设计模式，但自个儿写出来的代码就没那个味儿！

但，努力点，就总能改变，变得比之前的自己好些。智商不够，情商来凑，只能这么安慰自己了。

比如，在财务计算库存周转，资金周转时，每个人的设计方案都不一样。

有些朋友，喜欢用一个存储过程，搞定一切计算。

有些朋友，编程语言，比如Java,玩得很溜，就喜欢把数据拉到前端，放到他设计精妙的分布式计算引擎里面，跑数据。

还有些设计者，喜欢玩状态机，每一个周转点，设计一道snapshot(快照), 一个周期存一条记录，这样的数据表结构，CFO，通过看excel,也能看明白。

常看我朋友圈的朋友知道，18岁一晚上学会SQL的 CFO，玩起数据来，手段辣的很

在这里，我不想比较存储过程，编程语言，我只想谈设计快照，即数据建模的好处。

为了通俗易懂，先不说电子制造厂那么复杂的 MES系统，就拿京东购物的订单来举例：

你熬夜看 Apple, 终于等到了 iPhone13 香, 高刷，赞；短刘海，赞；存储1T，买了！

于是，每隔10分钟，刷新下京东订单，看看手机送到哪里了。如果正常，你会看到这样的页面：

乍看页面，似乎这样的设计很简单。无非抓取下订单状态，做下可视化。

订单状态，依靠扫描枪实现快速录入。那么设计一张表，就能搞定一切。

其实，这是外行看法。实际上，数据库的设计可以搞死UI，让页面性能严重拉胯。

京东2020年，活跃用户有4亿+，仅用一张表，承载那么多用户的订单状态，会发生什么！

订单状态图，是给用户看的，用来缓解焦虑。内部运营要看的是这样的统计报表：

这5个时间点，每段间隔，都能影响用户体验。但凡有一段时间拉的比较长，都可以考虑优化，也应该被优化。

比如，用户提交订单，到付款成功，如果耗时较长，那么说明系统的支付接口存在一定问题，需要排查：

再比如，等到收货到完成，是不是存在分派效率问题？谁愿意一下午守在家里，就等一个快递？

所有这些统计，仅仅凭一张订单状态表，是不可能做好的，尤其在海量用户的情境下。

这就要求，数据建模和业务分析，在理解数据结构上，有一定的积累

我知道，京东内部分析运营的时候，可能不会这么做BI Report

但用来解释，为什么我们需要好好考虑数据建模，这是说得通的.

为什么一张表搞不定这样的统计报表，现在应该明白了，照着那些原始数据，统计一个月所有订单的各个时间点的累计值，将会是一个巨大的吃资源的SQL

运营管理，经过多次迭代，才筛选出来的这5个时间点。如果需要增加或者调整这些时间点，基于原始表分析，又会产生大量的读，造成资源紧缩。

聪明如你，肯定想到了，每一次迭代都是一个版本，妥善管理这些版本的统计值，才能比较出管理的提升。

当我用类似的理念，来解释库存周转率的设计方案， CTO 他情不自禁的 WOW 了起来，爽快地在猎头争取的Percent上，加到了1万块

嗯，今天先分享到这里。下回一步步细说，在数据建模时，用到的3个“面向”思维，和建模工具，以及交付的产品