本文转载自微信公众号「有关SQL」，作者Lenis。转载本文请联系有关SQL公众号。
CRUD，其实也有难的时候
早年在电子厂，开发MES的时候，我经常自以为是的修改老王师傅的代码。王师傅，真的是姓王，(不是隔壁老王玩笑话里的老王)
老王，55岁了，35岁上的大学，自学计算机编程。
印象中，最深刻的是，BOM结构和工艺流程路线。这两个要素，可以说是整个MES与ERP中最复杂的数据结构。
可能外人一看，比如隔壁开发UI的朋友，觉得也没什么。不就是一增一删，一改一查么，能比 angular 双向绑定，适配IE/Chrome 浏览器还难么
但，做过的朋友，肯定做梦都在发誓，以后绝壁不碰这两玩意儿了。
玩笑归玩笑，但凡老板笑着来跟你谈点需求，你一定会拍着胸脯说，今天下班前搞定!你看做技术的朋友，就是没什么心眼儿，做事太直男。既然拍着胸脯说的，加班也要搞定，不是么
那么我呢，经常在这样拍胸脯的场景中，修改老王的代码，认为老王那种过度设计工艺路线的方法，简直耽误开发进度，差点意思。
在这里，我要解释下两个名词儿：
一，是MES, Manufacturing Execution System, 生产制造执行系统
MES是个庞然大物，成熟的行业应用软件。举例来说，制造一台iPhone所经过的所有工序，工人，机器，场地以及材料和经费，都会被MES采集到。
通过分析这些数据，提高质量，控制成本，扩大产能。所以，制造型企业，要上数字化战略，MES肯定先行一步。
二，是工艺路线，即零部件制造流程
下图是我在硅材料加工厂，做晶圆制造时，常用的制造工艺流程图。
一个程序员对芯片生产，能有多少理解?想当然的就认为，它的生产就是一个有序的事件流，步骤1，2，3，4 ……按部就班的走下去。
于是我就设计一张表，记录产品的生产进度，每个生产记录，都有一个工序字段，当道工序做完，就自动进入设计好的下一道工序。也就是大家在图里看到的黑线流水图。
我本以为天衣无缝，自动化到了极致，但事实上，并不是我想的那么简单。
图中，还有红色箭头部分。
由于每道工序，都可以单拎出来，贡献它的生产力。甚至，有的工序间，还有来回的加工。因此，真正上线运行时，状况百出。
当我规定了黑色箭头的流程，写好了响应程序。等正式上线用的时候，果不其然，没多久，工厂负责录入数据的操作员，就来书记办公室抱怨了。
“你们小黄写的程序，怎么到了抛光检测(一道硅材料工序)，就没有清洗(又一道硅材料工序)了”
“那你们也没有提，在抛光后检测后，不直接入库，还要继续做清洗啊。我以为就是一步步往下流的”
“来了这么久，不知道工序之间是可以相互回流的吗?你不去生产车间考察的吗”
我x
彻底懵了
闭门造车，我完全被带到沟里去了。我以为的程序，竟然完全没有按照我以为的那样跑。
这些计件拿钱的工人，那愤怒的眼神，就像是要冲上来，狠狠地打我的脸。“你小子坐着办公室，吹着空调，就写出来这些狗屎东西，白白浪费老娘的时间”
就这样，除了修补数据，我连夜把程序修改成配置工艺路线模式。心惊了好几天!
后来团建时，跟老王说到这个事儿，他也不禁笑呵呵的说到，这事儿我就知道你要翻车。工艺路线，我那么写，就是为了能让操作员有更大的灵活度，也方便记录不同工艺的优劣。写死了，你就只能填坑式地补，最后补录数据，自然就都成了你的事儿。
嗯，姜还是老的辣
多年后我再回顾与老王交谈的那个下午，我依然觉得，数据库模式设计的魅力，深深打动着我。
一个好的设计，抵得上好几百个小时的缺陷修补。项目做的越多，我就越害怕设计数据库结构。设计得有缺陷，自己就是那个别人口中的“猪队友”。设计的好，大家都认为那是理所当然。
新开一个项目，就像医生新接一个病人。苦乐自知，明知风险大，依然吾往矣。
那么有没有一招吃遍天下的设计呢，显然是没有的。电商，社交，租约，哪怕是问卷，都有各自的难处。但凡带有这种占便宜，赶进度的想法，最终都会在某个时刻，让你坠入深渊，将你打个措手不及。
再看kimball的维度建模，纵然他总结了每个行业的最佳设计，但行业一直在改变，模式设计还是必须日新月异。他的思想，给我最大的启发，不是那20多个经典的设计思维，而是永远不要因循守旧，必须小心谨慎，大胆创新。
