[[429949]]

本文轉載自微信公眾號「有關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多個經典的設計思維，而是永遠不要因循守舊，必須小心謹慎，大膽創新。