01, 隔壁写SQL的老王，55了

信息系统还停留在 Visual FoxPro 的那个年代，能独立写个 MIS 系统就有人要你的那个年代。我毕业了，在一家电子集团公司（国内第六）做 MES 开发，用 FoxPro 写界面，SQL Server 和 Oracle 做后台。

公司信息部总共有 16 名软硬件工程师，能写代码的有 9 名，小张会 Delphi, 小夏会 VB, 我擅长写 Vfp. 当然，现在的 90 后恐怕是不知道这些语言的，“这些都是啥，能写爬虫，还是能做数据分析，学会了能进BAT不 ？”

令人吃惊的是，最大年龄的老王，居然有 55 岁了，还是从别的公司借调过来，帮忙开发 MES 系统，也就是一个人在两家公司任职，收两份钱。(嗯，悄悄告诉你，加起来过万是肯定的。我那时不到1.5K )

老王从来都是信息部的首脑，虽然他不在PM的职位上。凡是有数据库的改动，代码的签入，都需要他老人家手工批。哪怕是一个字段，一个编辑框的方位，大小。

当然，我是不理会的。上去就把一个字段名字给改了，因那字段名意思老糊涂了，跟老王长得差不多。结果中午懒洋洋在午睡呢，老王一个电话来了，我不知道当天是怎么熬过来的，反正我就是被他叫到办公室，坐他旁边，看了他一下午是怎么写代码的。如何维护视图啦，如何给参数命名啦，如何设计表结构啦，听得我是耳朵嗡嗡的。

反正我就记住了一件事情，以后要改任何东西，先跟他说。

嘴上虽然依着老王的规矩来，但心里是千万个不愿意的。什么老思想嘛，改个表结构，改个表达式都要经过你同意。你不就是老了点嘛。各位看官可别笑，我敢打赌，你们开始编程时，心里肯定同样也不服气你们的 Leader 给你改的代码。

嘴上说着知道啦，下次不会啦。但是真正下次 checkin 代码的时候，还是会时不时加入自己的写法，我称之为微创新。当然有些会被打回来，有些还会被老王称赞，甚至还会问我从哪里看到这样的写法。他一问，我就更骄傲了。头扬得更高，话音更洪亮。有些朋友是不是在笑，说的是不是你？自己心虚的时候，音儿特别的小，十拿九稳的时候，找茬是不是声音更大？一点小九九，谁没年轻过啊！

02, 有种看看你2年前写的代码啊

二年后，老王退休了。

我们这波人开始各自负责起熟悉的 MES 模块来。按照老王的规矩，相安无事的处了半年，大家都似乎合作的很好，接口也非常顺畅，数据库之间数据的同步也没有太大的纰漏。

但你认为没有问题的时候，问题一定会来找你！

公司因为连年盈利，开始有资金沉淀，准备上线新的晶圆制作系统。这意味着老的 MES 需要重新改造。于是，每个人开始忙碌起来，似乎每个人都知道怎么去修改，因为大家都清楚了先前的流程，编码技艺上也没有太多的障碍了，所以各个胸有成竹。

随着第一次内审的到来，我们的MES缺陷才暴露无遗！

首先，新的晶圆制作系统已经改用了大英寸圆片，工艺路线早就发生了变化，但内审却没有从MES中明确的找到一条完整的路线，用现在的词来说，就是 workflow 不清晰。而MES仅停留在上一版的路线上，究其原因，我们每个人自己硬编码了一段路线在各自负责的模块里。

第二，整个生产线库存盘点不明晰。每个工艺完成时，应该有个半成品库来管理。我们倒是有半成品库，但从来都不集成，内审看到的都是零散的统计数据。老王曾经做了很多的视图，来连接各种统计表，但在我们后期做库存管控时，却一张都没用。不但没用，连库存这么重要的统计信息，都不曾想过去做个快照，纯粹是靠SQL去实时的算。

再拿老王的旧版一对比，我们 8 个人面面相觑，原来代码早就成了一锅粥，UI和SQL黏在了一起，完全分不开。

03, 你先写好这四题

没有对比，就没有伤害。

在 SQL 编程这件事情上，只有更好，没有最好。如果说算法是泛编程的魂儿，那么业务模型的表达，就是SQL的精髓。哪怕你SQL水平再好，碰到下一个项目，你也不敢说，一定就能hold住当前需求的模型设计。

比如，我这里有四个小题，你可以尝试自己想想模型如何建立？

A) 一张表中表达父子结构

B) 一张表中表达决策树

C) 表达双11历史价格销售差

D）银行流水增删改查