所有的業務系統都是在做資料的維護和讀取

在CSDN上讀了一文《資料庫時代的終結意味著什嗎？》，不大讚同作者的觀點，我的觀點如下：

資訊時代，資訊就是資料，資料也是資訊，誰包含誰我不想咬文嚼字。我的觀點如題：所有的業務系統都是在做資料的維護和讀取。

資料庫管理系統開發工作近8年，總結我的90%的工作內容都只有四個SQL語句：Select,Insert,Update,Delete。Select用的最多，因為所有的資料及各種統計分析報表最終目的是要人或程式來讀取的。

當然這是一個概括，Select是我對所有SQL查詢，包括複合查詢，各種統計分析報表和商業智慧分析結果的一個總稱。其它資料庫設計與管理工作都是對能更好的得到這個Select結果，我把這種結果稱為最終視圖，不同的使用者需要不同的視圖，視圖內容又是隨著時間隨時變化的，可能只是看一眼，也可能要列印出來，還可能由程式讀取或再做其它處理，如銀行轉賬，存款取款等等。

資料庫管理系統的開發就如“賣油翁”，無他，其實就是做資料的維護和讀取。

今年就30歲了，三十而立，程式人生不盡如人意，我以後要專註於做一個資料庫管理員，DBA才是我的興趣和理想。

完了，再向大家拜一個晚年，新年工作順利，萬事如意，牛年，你我都牛起來。

 

(內容可能有些籠統和單調，將後面我的回貼加到下面豐富一下）

 

 

#13樓 回貼

 

下班前寫完的，沒想到這麼多人關注，謝謝大家這麼捧場哈，新年頭一天，並不是想嘩眾取寵，只想發表一點點個人的見解，相互探討。

公說公有理，婆說婆有理，站的角度不同，結論當然也不一樣，我的觀點也只想說明資料庫儲存，結構設計，資料存取，效能最佳化是一個應用系統的重心，當然不一定非是關聯式資料庫，但畢竟我們日常99%都在用RDBMS和SQL。這也是我個人的興趣和發展方向。

我現在的工作也是軟體開發，從這個角度出發應該把企業商務邏輯做為中心，但同時我也負責資料庫設計甚至大部分DBA的工作，象我這樣的同學也不少吧。我的開發步驟就是先根據企業商務邏輯流程設計資料庫結構，然後再寫中間業務層，最後寫B/S或C/S的使用者介面。我沒有按測試驅動開發，資料庫設計似乎在測試驅動開發中隻字不提，或者根本就不是開發員的工作範圍。

我研究過K3/Agile/OracleEBS等大型系統的關聯式資料庫設計，95%的介面操作都不是對單個表的Select/Insert/Update/Delete，有非常多的企業商務邏輯不是在中間業務層或者應用程式代碼中實現的，而是在預存程序/SQL函數/解發器中實現的，經常在一個資料庫事務中包含對幾個甚至一二十個表的操作。所以，我才得出了這篇文章的觀點：資料庫儲存，結構設計，資料存取，效能最佳化是一個應用系統的重心或中心。

這裡又有一個引申議題，中間業務層是不是一定要在程式碼中實現，還是可以在資料庫的預存程序/SQL函數/解發器中實現呢，答案決不會是只選前者，預存程序實現商務邏輯也有非常大的效能優勢，但缺點可能是難以管理維護。

故大型系統的設計，部分中間業務層仍然包含在資料庫中，不信可以看一下K3/OracleEBS，SAP估計也不例外，銀行/電信系統更不用說，雖然後兩者我沒接觸過，誰說資料庫不重要呢。我曾做過一個計算BomCost的系統，完全用MSSQL預存程序/函數/觸發器設計，定期計算產生所有BOM的Cost，最終用Access項目直接連接MSSQL展現資料，沒有用其它任何語言或工具開發。
我是不是又說了一堆廢話呵，^_^，睡覺去了。

 

#15樓 回貼

金色海洋說的對，歸根結底還是物件導向的資料庫太不成熟，沒有廣泛應用的商業物件導向資料庫，所以我輩中人99%都使用RDBMS，而喜歡物件導向的同學就只好使用別人設計好的ORM架構了，

Oracle/DB2/SQL SERVER等資料庫管理系統現在都宣稱可以實現物件導向的資料存取，但試問，我們國內的軟體開發過程中實際應用有幾何，不足1%吧？。

我很少使用Java，恕我理解膚淺，Java僅僅是一種程式設計語言，只不過市場上有許多第三方組織用Java寫的ORM架構而已；同理C#也是一種程式設計語言，LINQ也是一種ORM架構而已。程式設計語言和資料庫存取有著緊密的關係，但完全是兩個概念，談何替代。