我們真的用好 SQL 數(shù)據(jù)庫了嗎？
本文轉(zhuǎn)載自微信公眾號「有關SQL」，作者Lenis。轉(zhuǎn)載本文請聯(lián)系有關SQL公眾號。
CRUD，其實也有難的時候
早年在電子廠，開發(fā)MES的時候，我經(jīng)常自以為是的修改老王師傅的代碼。王師傅，真的是姓王，(不是隔壁老王玩笑話里的老王)
老王，55歲了，35歲上的大學，自學計算機編程。
印象中，最深刻的是，BOM結構和工藝流程路線。這兩個要素，可以說是整個MES與ERP中最復雜的數(shù)據(jù)結構。
可能外人一看，比如隔壁開發(fā)UI的朋友，覺得也沒什么。不就是一增一刪，一改一查么，能比 angular 雙向綁定，適配IE/Chrome 瀏覽器還難么
但，做過的朋友，肯定做夢都在發(fā)誓，以后絕壁不碰這兩玩意兒了。
玩笑歸玩笑，但凡老板笑著來跟你談點需求，你一定會拍著胸脯說，今天下班前搞定!你看做技術的朋友，就是沒什么心眼兒，做事太直男。既然拍著胸脯說的，加班也要搞定，不是么
那么我呢，經(jīng)常在這樣拍胸脯的場景中，修改老王的代碼，認為老王那種過度設計工藝路線的方法，簡直耽誤開發(fā)進度，差點意思。
在這里，我要解釋下兩個名詞兒：
一，是MES, Manufacturing Execution System, 生產(chǎn)制造執(zhí)行系統(tǒng)
MES是個龐然大物，成熟的行業(yè)應用軟件。舉例來說，制造一臺iPhone所經(jīng)過的所有工序，工人，機器，場地以及材料和經(jīng)費，都會被MES采集到。
通過分析這些數(shù)據(jù)，提高質(zhì)量，控制成本，擴大產(chǎn)能。所以，制造型企業(yè)，要上數(shù)字化戰(zhàn)略，MES肯定先行一步。
二，是工藝路線，即零部件制造流程
下圖是我在硅材料加工廠，做晶圓制造時，常用的制造工藝流程圖。
一個程序員對芯片生產(chǎn)，能有多少理解?想當然的就認為，它的生產(chǎn)就是一個有序的事件流，步驟1，2，3，4 ……按部就班的走下去。
于是我就設計一張表，記錄產(chǎn)品的生產(chǎn)進度，每個生產(chǎn)記錄，都有一個工序字段，當?shù)拦ば蜃鐾辏妥詣舆M入設計好的下一道工序。也就是大家在圖里看到的黑線流水圖。
我本以為天衣無縫，自動化到了極致，但事實上，并不是我想的那么簡單。
圖中，還有紅色箭頭部分。
由于每道工序，都可以單拎出來，貢獻它的生產(chǎn)力。甚至，有的工序間，還有來回的加工。因此，真正上線運行時，狀況百出。
當我規(guī)定了黑色箭頭的流程，寫好了響應程序。等正式上線用的時候，果不其然，沒多久，工廠負責錄入數(shù)據(jù)的操作員，就來書記辦公室抱怨了。
“你們小黃寫的程序，怎么到了拋光檢測(一道硅材料工序)，就沒有清洗(又一道硅材料工序)了”
“那你們也沒有提，在拋光后檢測后，不直接入庫，還要繼續(xù)做清洗啊。我以為就是一步步往下流的”
“來了這么久，不知道工序之間是可以相互回流的嗎?你不去生產(chǎn)車間考察的嗎”
我x
徹底懵了
閉門造車，我完全被帶到溝里去了。我以為的程序，竟然完全沒有按照我以為的那樣跑。
這些計件拿錢的工人，那憤怒的眼神，就像是要沖上來，狠狠地打我的臉。“你小子坐著辦公室，吹著空調(diào)，就寫出來這些狗屎東西，白白浪費老娘的時間”
就這樣，除了修補數(shù)據(jù)，我連夜把程序修改成配置工藝路線模式。心驚了好幾天!
后來團建時，跟老王說到這個事兒，他也不禁笑呵呵的說到，這事兒我就知道你要翻車。工藝路線，我那么寫，就是為了能讓操作員有更大的靈活度，也方便記錄不同工藝的優(yōu)劣。寫死了，你就只能填坑式地補，最后補錄數(shù)據(jù)，自然就都成了你的事兒。
嗯，姜還是老的辣
多年后我再回顧與老王交談的那個下午，我依然覺得，數(shù)據(jù)庫模式設計的魅力，深深打動著我。
一個好的設計，抵得上好幾百個小時的缺陷修補。項目做的越多，我就越害怕設計數(shù)據(jù)庫結構。設計得有缺陷，自己就是那個別人口中的“豬隊友”。設計的好，大家都認為那是理所當然。
新開一個項目，就像醫(yī)生新接一個病人。苦樂自知，明知風險大，依然吾往矣。
那么有沒有一招吃遍天下的設計呢，顯然是沒有的。電商，社交，租約，哪怕是問卷，都有各自的難處。但凡帶有這種占便宜，趕進度的想法，最終都會在某個時刻，讓你墜入深淵，將你打個措手不及。
再看kimball的維度建模，縱然他總結了每個行業(yè)的最佳設計，但行業(yè)一直在改變，模式設計還是必須日新月異。他的思想，給我最大的啟發(fā)，不是那20多個經(jīng)典的設計思維，而是永遠不要因循守舊，必須小心謹慎，大膽創(chuàng)新。
