「以資料庫為開發核心」是筆者根據多年來多次開發企業資訊系統所累積的經驗總結。當然，這是筆者的個人體會，並不表示這是唯一的開發方法，只不過依此邏輯去推論，且經實戰的驗證，是一個可重複操作、彈性頗大且可跨開發平台的作法。所以就大著膽子寫下來，算是個人一些淺見的心得分享，請各位先進不吝指正。

簡單的說，所謂的「以資料庫為開發核心」有2個主軸

開發工具及程式語言，主要是負責使用者操作介面（User Interface）
商業邏輯全部寫在資料庫中的 Store Procedure及function

開發企業資訊系統的方法非常多，每一個架構師都會有自己的一套設計思惟，可以說是百花齊放。筆者親身參與至少不同版本的企業資訊系統（ERP、CRM等），從

DOS → Window 95 → Client Server → Web → Web 2.0 …

每一次更換開發語言

Clipper、VB5、Delphi、Visual Studio 2008…、PHP、ROR、Vue、React

或是作業系統平台

DOS、Window 95、Web、Cloud、iOS、Android

都必須被迫重寫所有的程式碼，一開始還不覺得有什麼不對，反正也只能任由工具大廠擺佈，該重寫就重寫。當然，部份原因也是為整個開發工具集還不夠完善，經驗也還累積的不夠多。但是內心深處總隱隱覺得不對，不過也還是只能隨波逐流。即便到了 Client/Server 架構的時代，資料庫也都已經升級使用MS-SQL，但也僅限於利用它來讀取及寫入資料，Store Procedure那是什麼？好像有聽過，User Define Fujnction（UDF）？好像聽過，但跟它不熟。

這種情況持續了很多年，突然有一天，「當Michael坐在蘋果樹下沉思，被天上掉下來的蘋果砸到頭…」，當然，這是牛頓的故事。真實的情況是Michael（就是小弟我啦）有一天碰到了一個程式設計的天才，跟他討論一個困擾Michael很久的問題，

如何大幅提昇MRP的展算速度」？

這個傢伙想了一下，和Michael仔細討論了計算的邏輯，隔天就展示了一段Store Procedure，不試就算了，一試之下驚為天人，速度是原先寫程式跑迴圈的舊方法的10倍速不止，當下大為折服，從此就成了SQL的信徒。

「從此公主與王子就過著幸福快樂的日子…」

No、No、No，這不是結束，故事才剛開始。領教了SQL的高效，但由於績習難改，而且原系統已經完工，所以筆者並沒有全部改寫，而只是將幾段效率較差的程式碼（如月加權成本計算等）改寫為Store Procedure，只算是入了門，但離大成還有漫漫長路。

    如此，又過了幾年，筆者又參與了一個新專案的開發，這個專案計劃在一年中，將原本的ERP系統所有模組，移植到Web平台。由於在開發團隊中，熟悉Web開發的程式設計師嚴重不足，但是有幾位熟悉SQL的資深程式設計師，所以筆者被迫要想出最有效率的團隊工作模式，經過仔細的思考、反覆推敲，最後就得出「以資料庫為開發核心」的設計思惟，並開始在新專案中實作。簡單的說，就是把所有的商業邏輯及報表的取值都寫成Store Procedure、View及User Define Function，在這樣的架構下，程式開發工具主要的任務就是開發使用者操作介面，複雜的商業邏輯則交給資深的系統設計或分析師寫成Store Procedure供程式設計師呼叫使用。

    不同的程式開發工具，如 VB6，Delphi7，VS2012等，各有其各自不同的程式語法，你不可能把Delphi的程式碼移到PHP 或 Javascript 去使用、執行，當然您可以試著手動修改，不過難度頗高。然而，資料庫中的SQL語法相較之下，是有標準的，基本上，只要能遵守 ANSI-92以上的標準，大部份的SQL語法都可以相通。各家資料庫產品的SQL語法都會參考這個標準，再擴充進階的功能而成。這也就是說，只要寫SQL程式時，盡量都使用標準語法，在不同的資料庫管理程式中，幾乎都可以在適度修改後直接執行。

說實在的，這真是一個絕妙的主意，因為一旦有了標準，相關廠商就必須遵詢，否則就會被市場淘汰，如此就可以確保SQL程式的可移執性。程式設計是個非常勞心的工作，不斷的有學習不完的新技術會冒出來，同時又得面臨急迫的專案時程。有時候必須在很短的時間內熟悉一些最新的、重要的技術。

要熟悉一種新的開發語言，除了基本語法的學習必不可免，透過大量閱讀精湛的範例程式碼，更是非常有效的學習方法。SQL語法非常的簡潔，並不複雜，一般的程式設計人員通常都有一些基本的認識，但是要精通就不是件容易的事，觀念的轉換是最難打通的一關，需要長時間經驗的累績。

所謂「觀念的打通」，主要指的是「捨迴圈而用批次」。大部份的程式設計師在處理大量資料的運算時，習慣性的會使用迴圈一筆一筆的累計計算，這在資料量少時，不會有問題，但隨著輸入資料的日漸增多，執行的效率就會越來越差，通常系統上線的初期，使用者還沒有感覺，但使用一段時間後，就會開始反應系統越來越慢，有時還會像當機一樣。而當程式師檢查程式碼時，程式通常也沒有錯誤，常會歸咎於網路不穩定，使用者操作習慣不良… 等未知的原因。

想要真正的發揮「關連式資料庫」的效能及強項，真正的難點並不是SQL語法的學習，絕大部份的軟體研發人員都略懂SQL語法，因為這是和資料庫溝通的標準語言。但是多數負責寫程式的工程師，通常都是透過開發工具（如早期的 VB6、Delphi、PowerBuilder，或是近期的 Visual Studio 2008、2012、2015等），所提供的元件，透過簡單的設定，並撰寫一些簡單的SQL語句，就可以和資料庫溝通。做一些簡單的查詢、新增、修改、刪除等作業。這也是大多數軟體工程師使用SQL的方式。

這當然沒錯，而且也是必要的程式寫法，但是如果只是這樣使用關聯式資料庫，就會像倚天屠龍記中的張無忌，雖然身負九陽神功，內力之強舉世無雙，一旦被困在光明頂上，還是得透過小昭的協助學會了乾坤大挪移，理解了巧力的運用法門，才得以破關而出。關聯式資料庫就像是九陽神功，博大精深且功能強大，而關聯式資料庫中的 Store Procedure、Trigger、user defined function 等，就像是乾坤大挪移，每練深一層，功夫就更上一層樓，更懂得使力的技巧。

學習SQL的過程，的確和練乾坤大挪移的過程非常類似。如果沒有九陽神功的深厚內力基礎，張無忌就會和歷代的明教教主一樣，窮其畢生的精力，也只能初窺門徑，但永遠無法登堂入室。SQL的基礎相對就複雜一點，除了資料庫的必備基礎知識之外，還必須對整套企業資訊系統的資料表結構及關連非常熟悉。

所以在討論開發企業資訊系統時，如果只是一昧地在工具的選型及專案的執行方法論打轉，而忽略了開發方法論，這無疑是有很高的風險，在稍後的系列文，也會有一些章節專門來討論。當然，本系列文的重點還是在「以資料庫為開發核心」，所以接下來的內容會比較硬一點，要說明一些 Store Procedure 等 SQL 語法的基本重點，盡量會針對 MS-SQL 及 MariaDB 來同時說明。希望您能耐心的看下去。感謝您的收看，我們明天見。