減小存儲過程封裝業務邏輯-web開發與傳統軟件開發的思惟模式不一樣

本篇文章討論並非：不要使用存儲過程,由於有些事情仍是要存儲過程來完成,不可能不用。而是關於："業務邏輯是否是要封裝在存儲過程當中實現，這樣子php、java等就是調用存儲過程"。

 

業務邏輯，通俗說就是：好比要取數據的操做，取出會員編號爲x的數據，原來咱們通常是封裝成函數，或者直接編寫sql語句查詢。如今是交給數據庫的存儲過程去完成。

+------------------------------------------------------------

                 寫這篇文章的原因

+------------------------------------------------------------

在一家公司，老闆請工商銀行的一個技術總監(老闆本身說是總監，具體不知道)來跟咱們聊聊，我猜是老闆的朋友，相互交流一下。那個技術總監跟我聊的時候，讓咱們把存儲過程發給他，他回去看看。打住。聽到這個我就感受很詫異，當時我內心就想，咱們作web開發不多使用存儲過程來實現業務邏輯的，他讓我發存儲過程，確實沒法發哦。只能說沒有。

有一點我比較確定，在互聯網開發中，把業務邏輯封裝在存儲過程來實現的作法比較少，從我之前呆的都是互聯網公司來看，確實不多使用存儲過程實現業務邏輯。

由於在此以前，我看過支付寶數據庫架構師馮大輝的經驗分享(http://www.infoq.com/cn/presentations/fengdahui-mysql),他特地提到儘可能不要用存儲過程來實現業務邏輯。當時我把觀點記錄下來了：

存儲過程能不用盡可能不用,原則是:業務邏輯不要封裝在數據庫裏面(數據庫去進行邏輯判斷業務)。把業務邏輯要交給應用程序處理。這樣能夠減小數據庫資源消耗。人員也難以招聘，由於既懂存儲過程，又懂業務的人少。使用困難。大量業務邏輯封裝在存儲過程當中，形成後面根本就不能動了。動a影響b。之後業務邏輯很難剝離出來。增長之後維護困難。

我記得當時他還特地舉例說了上海一家遊戲公司用存儲過程來封裝業務邏輯，後來改業務邏輯很是麻煩(我估計是既懂程序又懂存儲過程的確實少)。

 

 

 

因而我去搜索資料，我發現一個狀況，在電信、銀行業、金融方面以及國企都廣泛使用存儲過程來熟悉業務邏輯，可是這種經驗放到互聯網未必是對的。

看知乎上面這篇文章以下：

http://www.zhihu.com/question/19920716

 ================================

公司技術總監偏心用存儲過程來實現全部業務邏輯，請問這有什麼弊端嗎？

咱們有企業內部應用和互聯網應用，他都主張使用存儲過程來實現全部業務邏輯，並用他參與過的廣東省移動省級項目中使用存儲過程實現用戶登陸等例子來講服咱們。如今數據庫用的是SQL SERVER2005

添加評論 分享

什麼是答案總結？答案總結

贊同 2反對，不會顯示你的姓名

2

allen zhang，我喜歡計算機軟件技術

收起

羅燦鋒、譚永學 贊同

利弊是相對的，使用存儲過程來實現不必定是什麼「滔天大罪」，這徹底取決於系統的規模，擴展性以及產品的發展方向。
一般狀況來講，把業務邏輯寫到存儲過程當中不利於系統分層設計和維護，更不利於數據庫的遷移（固然沒有誰總想着換個數據庫玩兒玩兒），這麼作的緣由極可能是他認爲能夠提升性能（存儲過程的性能確實優於SQL訪問的性能），不過爲了解決性能問題有不少種方案，這種方式可能會差一些。

 

 ============================

上面這裏有個網友就說他們技術經理主張使用存儲過程來實現業務邏輯。我如今發現一點，從國企，銀行裏面來的，都是很是鍾愛存儲過程來實現業務邏輯的。這也是由於沒經歷過互聯網公司狀況所致。

使用存儲過程，他們提的最大優勢是和理由是：執行速度更快。不須要通過數據庫服務器解析，提升執行速度，由於預先編譯了。sql注入徹底屏蔽很是安全(安全能夠有他方案，更可能是一種總體取捨，而不是單純一方面考慮)

 

 

 

 

 

 

銀行業廣泛使用存儲過程封裝業務邏輯，我在搜索ibatis的時候，發現一個資料，來源爲http://baike.baidu.com/link?url=-suKmDp850my0GFevZvApmW09t_dYIzx5hW-KUGNPn5fyeojVmNHy-Pv4N2pu6CC

提到以下內容：

========================================
在筆者的系統諮詢工做過程當中，經常遇到如下狀況：
1． 系統的部分或所有數據來自現有數據庫，處於安全考慮，只對開發團隊提供幾條Select SQL（或存儲過程）以獲取所需數據，具體的表結構不予公開。
2． 開發規範中要求，全部牽涉到業務邏輯部分的數據庫操做，必須在數據庫層由存儲過程實現（就筆者工做所面向的金融行業而言，工商銀行、中國銀行、交通銀行，都在開發規範中嚴格指定）
3． 系統數據處理量巨大，性能要求極爲苛刻，這每每意味着咱們必須經過通過高度優化的SQL語句（或存儲過程）才能達到系統性能設計指標。

 

===========================================

 

 

還有不少技術會鄙視：程序員，爲什不用存儲過程來封裝業務邏輯，我看到一個網友以下批評那些不使用存儲過程封裝業務邏輯的程序員：

 

這種思路很廣泛，致使不少時候，濫用！
我就遇到一個問題，從一堆數據中找出知足條件的某些數據，把全部的數據從數據庫讀取到客戶端，而後計算，篩選數據！我問他爲何不考慮存儲過程，爲何不在數據庫端篩選數據？系統工程師回答的是，存儲過程對程序的移植性很差（若是換了數據庫，就得從新實現一套，起始，不少數據庫的sql語法都不同，換了數據庫，難道應用程序就不從新寫sql語句了？若是徹底適應SQL標準的sql語句，那就沒法發揮出數據庫自身的優點了），還有就是代碼維護起來不方便，看不到存儲過程的代碼，難於找出錯誤！哎。。。無語啊！

================================

其實，我很是認同這個系統工程師的見解，使用存儲過程移植性很差。確實對於開發人員來講，難以調試bug，定位錯誤。以前淘寶網就是遇到這種問題帶多。固然讓大家dba去找錯誤，開發人員就無法作。那麼都變成dba來實現業務邏輯或者是程序員都要學習存儲過程編程。

對於這句：換了數據庫，難道應用程序就不從新寫sql語句了？

個人見解：不是有pdo之類的數據庫透明層來解決嗎？能夠屏蔽對具體mysql仍是oracle數據庫的依賴。

 

 

 

 

+-----------------------------------------------------------------

我寫本篇文章表達兩個主要觀點(也方便之後與人討論)

+-----------------------------------------------------------------

 

這篇文章我只是想表達兩個觀點：

一、一樣是軟件開發，可是細分起來，經驗不必定通用的。存儲過程實現業務邏輯這種方式在傳統軟件開發領域以及電信、金融廣泛使用。

其實，我一直以爲，互聯網的web開發與傳統軟件開發思惟方式有些不一樣！

 

二、不能被所謂的10年8年開發經驗的標籤所影響。一我的即使是作了8年10年軟件開發，可是放到不一樣的領域去，有些經驗是錯誤的。

我發現，若是公司是運營網站的，請一個作金融，銀行的什麼技術總監來。實際上web開發與傳統軟件開發思惟模式不一樣。web開發需求也是頻繁跟着用戶去變的。須要的技能是不一樣。但外行的老闆們會覺得：作技術10多年了。應該不錯哦。請來............

 其實，我一直在我有把握肯定web開發應該如何作時，就很是抵觸。像那個遊戲公司就徹底搞混了。所謂術業有專攻,即使我不必定經歷不少高併發環境，可是因爲一我的在這個領域，他會常常去關注這個領域的成熟經驗和作法，那麼就會知道什麼是坑。

一樣是技術。呆的領域不一樣。經驗就不一樣。把那個存儲過程放到互聯網就出現不少麻煩，擴展性。工做量。

舉個親身例子：我之前呆的公司技術經理是79年的。他可能之前是作java企業級軟件開發的,不是作web開發。因此應該沒接觸過互聯網的產品模式(網站大流量要求性能和速度,服務器要抗住)，有次，我發現老闆看競爭對手的網站速度訪問快了那麼點點,怎麼會快些，估計不能落後吧（畢竟網站訪問速度對用戶仍是挺重要的），因而想讓技術經理優化，哪天咱們晚上技術部都加班，結果都沒折騰個方案來，經理總是在折騰網站http發送的頭部之類的，參考對手網站：咦，他們請求的時候發了一個頭，我網站也試一試,看能不能有提高.....。其實當時我也沒啥經驗,才畢業2年不到嘛。但對技術經理的要求固然不一樣，以如今的角度來見解,只要是長期作web開發，對於網站速度這種問題其實會造成一個套路，絕對不是靠猜想，試來試去的。找瓶頸在哪裏。是數據庫仍是代碼。均可以用軟件來統計數據的，統計出瓶頸在哪裏。靠猜想就會作無用功。使用主要矛盾法(技術術語就是找瓶頸，不是抱着多多益善的方式去試)，把主要矛盾解決了。其餘不是影響很大。後面再去作。

之前我總結那麼點點經驗,不必定正確,只是一點見解，後面沒去更新過：http://www.cnblogs.com/wangtao_20/archive/2012/05/10/2493899.html，http://www.cnblogs.com/wangtao_20/p/3304665.html。

當時的技術經理儘管作了8-10年軟件開發，可是接觸的不是web開發，因此網站速度優化的時候也是走了很多彎路。至少我以爲若是他是從事web開發的話，遇到這種網站速度和性能優化問題，對他這麼多年徹底是小菜一碟的。其實還好的是，咱們當時那種電子商務網站儘管流量和銷售額都不少,可是其實併發並不怎麼大.弄個mysql主從架構其實就把負載問題給解決了

 

ps:前面網友提到那個技術經理以參與過廣東省移動省級項目來講服，表面看頗有說服力：省級的移動項目啊.......。但我有本身的思考和判斷力，不在同一個領域，思惟是不一樣的。

 

 

 

 

 

 

後來我大量看了一些資料，你們對於使用存儲過程封裝業務邏輯的好處，概括起來有如下幾點：

一、  執行速度快。由於存儲過程不須要解析。預先編譯了

二、安全性。避免了sql注入，避免了暴露表結構和字段

 

存儲過程能夠避免SQL注入是什麼道理？

我以前覺得是能夠避免url中sql注入。後來才明白其實就是針對程序員或者技術而言的：技術徹底不知道表結構是什麼。獲取數據只須要調用存儲過程便可。原來是針對開發人員而言的，屏蔽他們對數據庫的權限(這麼看來，我以爲這些在電信，銀行作開發的程序員，其實技能很難提高的，就是調用寫好的存儲過程，不須要指導表結構，你也不用參與表結構涉及與優化，數據庫優化都不用管)，題外話。這樣子狀況下，放到互聯網去作開發反而經驗沒法套用了。

在url中注入方面。使用存儲過程與不使用存儲過程都是須要防範的。

存儲過程相似於函數，函數的參數預約了參數類型是int仍是char等。傳入的參數不是int型，會自動轉換成int型，從這個角度就是避免了sql注入(我以爲更可能是怕開發人員搞鬼 呵呵)。

看到網上有人說：用參數，只能說MS給咱們作了一些過濾，SqlParameter規定了你傳參數的大小類型
嚴格過濾還得你本身來 。

 

 

我在想，至於嚴格的判斷仍是得本身在編寫存儲過程的時候作嚴格的過濾。這就像在編寫java、php代碼進行組裝sql的時候作嚴格的過濾是同樣的。從這點來只不過一個是在存儲過程編程實現，一個在php、java端實現。

 

有網友提到：在存儲過程裏用set來拼接sql語句和直接在代碼中拼接沒有一點區別......而select * from table where name=@p1這種形式纔是安全的.....

 

若是你的存儲過程裏面沒有用參數來拼接sql的話就不會被注入，若是仍是拼接，哪和程序代碼拼接是一個道理

 

我也這麼以爲，因此我看最大好處仍是屏蔽掉程序員(屏蔽掉不懂技術的用戶那使用php實現也是同樣的)，程序員直接調用存儲過程。根本不知道表結構是什麼，有什麼字段，沒有直接暴露表名以及字段名給程序員。銀行這類系統安全性第一。程序員人員離職了，也不會影響,只知道存儲過程，談不上攻擊。只有幾個核心的人知道表結構。

 

 

 

可是，在互聯網產品開發中(通俗理解爲網站也能夠)，不同意使用存儲過程(淘寶阿里巴巴的架dba不同意使用存儲過程)封裝業務邏輯的人理由概括爲以下幾點：

一、  業務邏輯封裝在存儲過程當中。對數據庫的依賴性比較大。一旦要遷移數據庫,好比從oracle遷移到mysql等，之前的業務邏輯都得重寫(由於存儲過程是具體的數據庫系統產物,不一樣的數據庫語法不一樣)。編寫的程序儘可能要少依賴於具體的數據庫

 

跟臺灣一個工程師聊天，收穫以下：

其1、他的原則是編寫的程序不要太依賴於數據庫。他說像存儲過程,觸發器,關聯,視圖表等他幾乎不用

其2、提到有些應用使用存儲過程，依賴於數據去實現。他分析緣由比較中肯：
他們是很特殊的情況
他們追求的是高效率
並且有錢
他們的機房動輒幾百萬的投資,不是通常小企業能承受的
小企業今天程序可能放在公司,明天可能要搬移到機房
太過於依賴外在因素會死人的

其實大企業我徹底不反對他們依賴數據庫,我表弟的工做就是每天寫oracle的輔助程序
徹底是依賴數據庫
沒辦法,他在臺灣電力

概括爲：電信，金融這些企業佔據了很大的資源優點，有錢，關係能夠提供好的機房(帶寬和網絡穩定優點)。oracle數據庫上千萬的費用都能承受。
硬件多是定製的，好比花錢購買sun之類的公司的一套設備：操做系統到數據庫，徹底依賴於某個操做系統和數據庫來實現。

 

 

二、其實在互聯網高併發，大流量的狀況下，成熟的作法都是，計算層交給web層，數據庫只是存儲數據。儘可能少讓數據庫去作運算(也就是ifelse之類的邏輯判斷)，不要讓腳去作腦瓜子要作的的事情。從這個角度，就是要把計算數據，判斷之類的都交給應用代碼去解決。不要加劇數據庫的負擔(我以爲，銀行業可能不這樣子作，他們購買昂貴oracle數據庫和ibm之類的服務器一臺可能幾百萬來提升性能)

好比維基百科從mysql遷移到mariadb數據庫。不少互聯網企業隨着數據量大，出於節省成本考慮，遷移數據庫很日常的事情。

http://database.51cto.com/art/201304/391559.htm

 

 

二、  方便擴展。遇到數據庫性能瓶頸。單臺數據庫服務器永遠會存在瓶頸的(極限)，是扛不住的。集中式最終會被分佈式給替代，通常在互聯網環境下偏向於使用分佈式部署數據庫。分佈式通俗理解，要分庫，拆分表。拆分到多臺服務器上去。分散壓力。若是業務邏輯封裝在存儲過程當中。則很差這樣子作。由於存儲過程是依賴於某個具體的庫的。把計算層放到web層，那麼web端的程序只是從多個數據庫服務器聚合數據便可了。

google、阿里巴巴其實會經過不少mysql集羣來提升性能。

 

三、  互聯網應用頻繁修改功能，需求變化快。要響應用戶需求爲準，這關係到企業的生存。國企每每是資源豐富，大手筆很正常，功能頻繁修改來響應市場用戶？若是封裝在存儲過程當中，修改功能。維護確實麻煩。其實我以爲，還要考慮招聘成本。很難有既熟悉java又熟悉存儲過程編程的人(一門語言懂一點點是能夠作到)。銀行業，金融業不會頻繁的修改功能。我以爲，工商銀行會爲你了一個顧客說要什麼就加一個功能嗎？不會。咱們去看看工商銀行的網站就知道用戶體驗怎樣，也同時看看電信的。在國企的思惟模式不一樣的。敏捷開發在互聯網是常常用到的。

 

 

若是再讓我跟國企、電信、移動、銀行業的技術人員溝通，我仍然堅持，儘可能少使用存儲過程封裝業務邏輯。

 

正如前面網友說的，爲了解決性能問題有不少種方案，這種方式可能會差一些，不利於數據庫擴展，數據切分。

其實，不少真正提升效率的終極辦法是使用緩存而不是在數據庫中運算，靠數據庫預編譯或減小網絡流量那點優化就能夠，那說明性能要求本來不高。能夠去了解google，亞馬遜，淘寶網，新浪等是如何作的。像電信他們那樣子大量提升硬件治標不治本，而是用分佈式代替，就像人，單我的總再強老是存在極限的。因此使用存儲過程速度更快，那點速度的提高其實微不足道。根本沒法解決本質問題。

 

其實，銀行業爲何要使用存儲過程封裝業務邏輯。後面會分析出深層次緣由：絕對安全考慮！基於不差錢(依賴於具體的oracle數據庫又如何?)的大前提來作的。

 

實際上，我也以爲，使用存儲過程確實減小了二次解析，提升了效率，可是這種效率提到徹底能夠用其餘方式替代。損失的是擴展性。

http://www.zhihu.com/question/19767412
整體答案是，企業級內部系統，能夠使用。
互聯網必定要少用。這是經驗。經歷過教訓的。由於互聯網應用是一個對全部人都開放訪問的系統(越多人訪問商業價值越大)，沒法預估將來的用戶量，數據量的。之後要擴展就很是麻煩了。

有人想到了：淘寶在mysql中不照樣在用？據我從知乎上了解到，阿里從oracle遷移到mysql仍是要保留了必定數量的存儲過程，是由於歷史緣由的殘留(多是oracle有不少存儲過程殘留，無法一會兒改掉，系統提供服務運行穩定爲主)。搞清楚緣由了後更加有利於選擇。

不是單純的站在使用存儲過程"不須要編譯，提升了效率"這個點，提升了速度的角度去考慮問題。要從總體上：開發成本，之後的維護成本，系統的擴展性，擴容等等。進行權衡取捨。
用這種方式提升了速度，可是系統的擴展性，維護性，開發成本？

不少人讓其給建議，也不會直接說必定不用。也只是委婉的(mysql dba)：

能夠用,若是你很明確本身的容量和性能,很熟悉存儲過程的開發.說點其餘的:
1. 隨着海量的數據增加,高併發的系統,數據庫慢慢轉化爲僅僅做爲數據的容器. 若是你的數據庫存在瓶頸,存儲器,觸發器這些都沒用了.
2. 從web層擴展是很容易的.因此把計算留給web層吧.

====================================另一位

不能一律而論，對於和屬於相關性大的業務邏輯和計算，Oracle徹底能勝任，邏輯轉移到Web層反倒複雜。
=============================================
我想這也是oracle把計算層放在數據庫層的緣由吧。因此在oracle中能夠使用存儲過程。

-----------------
阿里、淘寶的大牛dba們強烈建議在mysql庫中，儘可能不要使用存儲過程，不易維護，出問題跟蹤十分麻煩，從管理的角度我很認同這樣的觀點，
從實現上來時存儲過程也是具有必定的優點的，看場景選用，能不用則不用爲妥。
須要先預編譯，在實際中不是常常用到，固然還要看是什麼樣的項目來決定。

 

分析：數據庫用來作他擅長的事情，存儲數據。把數據庫當成一個存儲數據的地方。計算的事情儘可能交給程序應用層來處理。跟現實中的哲學：不要讓大腦幹其不擅長的事情。大腦適合幹腦力活想事情，你恰恰安排到去作體力：拼頭力氣大小。

 

 

 

 

也有人提到：

數據庫是至關昂貴的投資，能讓他多幹點就多幹點活。存儲過程的優點仍是很是強的（在沒有跨平臺的要求下）。貌似咱們公司那幫java的就歷來不知道存儲過程爲什麼物，用java的框架統一輩子成，處處是拼接SQL.
---------------------------------

數據庫是昂貴的投資是oralce的說法，mysql是免費的

----------------------------------

存儲過程做爲一種過期的語言，只能存在於較少的業務場景了，好比規範的數據倉庫數據清洗、標準、簡單的多數據庫操做等。
在良好的業務系統中應該儘可能拋棄存儲過程和觸發器之類的東西。
一、從設計角度看，邏輯封裝很重要，不是存儲過程那一點封裝，而是整個業務邏輯。若是把業務邏輯分散在程序代碼和存儲過程兩部分，其實是業務碎片化，不利於表述業務邏輯，形成後期閱讀維護的困難。

二、存儲過程自身並非一種結構化良好的語言，對於習慣於面向對象編程的人而言，簡直就是亂麻一堆。代碼可讀性在工程上很重要。
三、不少真正提升效率的終極辦法是使用緩存而不是在數據庫中運算，靠數據庫預編譯或減小網絡流量那點優化就能夠，那說明性能要求本來不高

四、若是有數據庫解耦的需求，就更不該該使用存儲過程

好的架構師可能是從程序員發展來的，有幾個是DBA發展來的？有幾個好的架構師常推薦存儲過程呢？因此DBA兄弟們最好仍是聽程序員的話，優化sql便可。
若是真想從架構思路上去優化，先應該全盤考慮系統架構問題。

 

=========================================

 

 

 

 

 

 ==================================================================

                       最後概括

 ==================================================================

 

業務邏輯封裝在存儲過程當中，是要看場景使用

1、若是是金融，銀行，電信等國企類。使用存儲過程影響不大。這種狀況是持續了不少年。

好處：

一、銀行類系統對於安全性要求很高，存儲過程把sql封裝起來，徹底能夠屏蔽sql注入(也不是沒替代方案，互聯網也有安全性要求比較高的，好比在線支付均可以有其餘方式來解決)

 

二、對系統的速度要求很高。每每是經過花大價錢購買硬件和oracle之類的數據庫服務來解決問題，這些企業很是有錢，能夠經過花錢購買oracle數據庫，良好的硬件來解決。好比一臺機子上幾百萬均可以承受。只要能保證我安全,花錢能夠接受。反而在互聯網環境下，爲了節省成本，互聯網大部分公司面對性能瓶頸， 更多使用大量廉價的pc server(一萬左右一臺)來作集羣，從集中式向分佈式進行部署。google之前也是使用大量廉價的mysql集羣(使用存儲過程是無法作到分佈式查詢,存儲過程原本就是在一個庫下面)，依賴於某個單個庫）。

另外，解決性能瓶頸，互聯網大部分仍是經過使用緩存來解決的，這跟銀行類系統"花費大價錢提升硬件和數據庫軟件的承載能力"思路是不一樣的。

 

從這個角度來講，我其實不以爲電信行業這些人技術多麼牛逼。緣由在於，他們提升性能的方式其實更可能是經過花費大量的錢來購買oracle商業的數據庫以及ibm之類的小型中型服務器抗住。通俗說，就是商業公司幫助解決的。

 

關於oracle數據庫：

Oracle主要是依賴中高檔存儲設備和小型機；而中高檔存儲設備和小型機的購買費用很是貴，更關鍵是這些設備的保養費服務費用更加貴，甚至超過設備購買費用；

Oracle不適合大數據量採用PC Server+僞分佈式的模式

Version:0.9 StartHTML:-1 EndHTML:-1 StartFragment:00000099 EndFragment:00000813

Oracle 11G的User License無限使用期的價格爲人民幣3千5左右，按50個User License無限使用期的購買量則價格爲17.5萬(50* 3500)

每一個CPU License無限使用期的價格爲17萬9千。

每一年是20%的服務費(第一年免費)。

 

我查資料得知小型機(其實我也被這個小字給誤解了)：

使用IBM Power系列處理器的System p服務器統稱爲「小型機」，是區別於X86構架的System X系列服務器的一種稱呼。不要覺得這個系列的服務器名稱中帶一個「小」字就小看了他的性能，要知道基於X86構架的計算機設備是被成爲「微型機」的。Power處理器區別於Intel至強、AMD皓龍的根本性指標是前者運行精簡指令集，然後二者運行復雜指令集，相比之下Power效率更高，併發處理能力更強。採用IBM Power處理器的服務器運行基於UNIX開發的操做系統AIX，通常應用於網絡基礎構架的後端數據庫訪問控制或者高性能科學計算領域。

說白了 比通常服務器更要好全部的東西都是IBM 幾十年來本身開發的 裏面的CPU 就要比因特爾的要強不少 固然也很是的貴 基本上最好都是幾十萬的 幾百萬的也有

型號麼 通常你看見IBM P550 P570 等等就是小型機了

由於IBM小型機是運行Unix系統（Aix），因此在這個平臺上面運行的軟件

 通常都是基於Java的開發系統，好比應用與銀行中介於大型機和普通服務器之間的連接，電信中的中端架構，還有企業，政府中的要求高端運行，高穩定，超低宕機要求的系統。

反推一下，全部不能應用windows,linux 系統的地方基本上都是小型機的天下，而這些裏面大部分應用的是IBM 的Aix系統小型機

 小型機我看到報價是25萬，90萬的。

 

 

 

 

我能夠概括爲：花費了大手筆購買的服務器，超強。聽說是整年不宕機，很是穩定。性能很牛逼。

 

那麼總結就有錢，不在意這點錢。

多花錢，能解決我問題就好(保障穩定服務以及安全也很值得)。

 

使用存儲過程封裝了業務邏輯，依賴死具體的oracle數據庫不要緊(oracle在pc server上是跑不了的，必須在昂貴的小型機機上才能發揮優點)，電信企業幾十年使用oracle，依賴死都不要緊。

我強烈感慨，電信行業這些的技術經驗放到互聯網大部分民企是行不通的。google那麼有錢，仍然要使用大量廉價的pc server。阿里巴巴那麼有錢，尚且要把大量數據遷移到mysql作集羣，我以爲緣由在於：民營企業是要以生存爲準的。成本考慮第一。

 

三、銀行類的系統需求不會頻繁的變動。功能不能頻繁修改，加功能，我以爲銀行之類系統不是以用戶須要什麼功能爲標準的，你看看工商銀行的網站，功能很好嗎?。他們是老大。相對互聯網環境下，web開發得不停響應用戶體驗需求，加新功能是不一樣的。互聯網面對全部用戶都能開放訪問的環境下，須要開發功能快速響應。因此常常看到在互聯網使用的是敏捷開發。頻繁的系統功能修改與響應，這種環境下，業務邏輯改動比較多(生存壓力，用戶須要什麼你就給什麼)，那麼，若是使用存儲過程的話，改代碼，調試代碼都會比較麻煩。

 

其實，我去看mysql5.1手冊中提到存儲過程，介紹以下：

MySQL 5.1版支持存儲程序和函數。一個存儲程序是能夠被存儲在服務器中的一套SQL語句。一旦它被存儲了，客戶端不須要再從新發布單獨的語句，而是能夠引用存儲程序來替代。

下面一些狀況下存儲程序尤爲有用：

·         當用不一樣語言編寫多客戶應用程序，或多客戶應用程序在不一樣平臺上運行且須要執行相同的數據庫操做之時。

·         安全極爲重要之時。好比，銀行對全部普通操做使用存儲程序。這提供一個堅固而安全的環境，程序能夠確保每個操做都被妥善記入日誌。在這樣一個設置中，應用程序和用戶不可能直接訪問數據庫表，可是僅能夠執行指定的存儲程序。

存儲程序能夠提供改良後的性能，由於只有較少的信息須要在服務器和客戶算之間傳送。代價是增長數據庫服務器系統的負荷，由於更多的工做在服務器這邊完成，更少的在客戶端（應用程序）那邊完成上。若是許多客戶端機器（好比網頁服務器）只由一個或少數幾個數據庫服務器提供服務，能夠考慮一下存儲程序。

存儲程序也容許你在數據庫服務器上有函數庫。這是一個被現代應用程序語言共享的特徵，它容許這樣的內部設計，好比經過使用類。使用這些客戶端應用程序語言特徵對甚至於數據庫使用範圍之外的編程人員都有好處。

 

我很是贊同這句話，安全很是重要的時候。銀行，金融業安全第一。其餘方面一律都不考慮(硬件花錢購買，軟件依賴於oracle之類昂貴的數據庫系統無所謂)

互聯網環境下，存儲過程用得仍是比較少的。安全性能夠有替代方案的。

 

2、web環境儘可能少用。用了弊大於利。使用存儲過程，業務邏輯封裝在存儲過程當中，修改功能，維護起來都比較費力。互聯網應用偏偏須要快速響應用戶需求的變化，應用變化很頻繁,業務邏輯修改若是去修改封裝業務邏輯的存儲過程就會變得很麻煩,就像在互聯網產品開發中，因爲應用頻繁變化,表結構常常須要修改是不少dba頭痛的事情(不能影響用戶操使用網站)。隨着網站用戶的增長，網站扛不住了，更可能是考慮水平擴展，作集羣。你或許能夠經過花費大價錢購買設備和數據庫服務 ，可是，單個硬件服務器、單個數據庫軟件承載是有極限的。做爲民營企業，你會考慮購買的成本是否扛得住,以前阿里巴巴一年的oracle投入須要4千萬左右，後來爲了減低成本使用mysql作集羣,具體參考：

http://www.linuxeden.com/html/news/20120413/122892.html

 

能減低成本爲何不減低呢？

互聯網是分佈式部署居多。經過廉價的pc server集羣來達到效果

淘寶有一個動做是去IOE（IBM的小型機、Oracle數據庫、EMC高端存儲）。早期的淘寶，主要靠的是高端硬件，思路就是用錢解決問題。可是這樣作的成本很高，淘寶的業務規模又擴張得太快，因此要用更經濟的方案。用PC Server、MySQL數據庫等，經過大量廉價的硬件，水平伸縮組成集羣，來替代昂貴的硬件，思路就是用技術解決問題。跟google的思路一致。

 

 

 

我一直以爲，技術主管對技術的嗅覺和預見性仍是有一些影響的，若是招聘一個銀行電信業的技術人員轉移到互聯網作web開發，其使用存儲過程封裝業務邏輯在之前看來是很成熟的經驗，可是放到互聯網web中去，多是一種早就埋下來的坑。

 之前聽一個網友提過，電子商務網站，對技術水平的要求倒並非很高(淘寶阿里巴巴等除外)，大部分只要扛得住便可。我比較認同這個觀點。基本的需求知足便可了。

我歷來不以爲凡客在使用存儲過程能夠做爲一個良好的佐證：人家不照樣在使用麼？有什麼不能用，咱們更多應該參考亞馬遜，ebay，阿里巴巴等企業的技術方案，向他們看齊。

 

 題外話，其實互聯網的數據大部分不像金融行業要求那麼嚴謹，丟失點點用戶數據不至於如何。對數據的一致性要求並非100%的苛刻。反而銀行出於絕對安全考慮，必需要封裝在存儲過程當中實現業務邏輯。其實如今也逐漸看到，金融行業在一些非關鍵性的業務數據使用mysql，好比日誌統計，行爲分析等。

 

用金融、電信、銀行業的開發思惟方式來考慮互聯網，經驗不適應，成本提升了不少不說，對於將來的升級和擴展還確實是一個坑(固然不差錢就好辦,有時候錢多人傻也沒有)。

 

知乎上面討論的京東使用的成本：http://www.zhihu.com/question/19818863，也挺有趣的。對於一個利潤不是很大的零售業來講，要付出很大一筆錢給微軟,微軟仍是比較封閉的。如下這個網友的觀點很是好：

 

 

用.Net，意外着你被捆綁在Windows平臺上。不是.Net效率自己比Java,PHP差，語言其實差異很小，差距在於：

1. Windows Server受權費太貴，Linux免費，若是你有上千臺服務器須要買上千臺Windows受權(這跟使用oracle的思路是同樣的)......

2. Windows不但貴，性能還遠遠不如Linux，注意這裏說的是服務器端性能，跟桌面一點關係都沒有

3. 許許多多無數的開源、高端服務器組件只有Linux/Unix版本，移植到Windows上的基本是半殘品

4. 許許多多優化技術、高性能分佈式緩存、數據庫、NoSQL解決方案等等，僅針對Linux

5. 你須要的一切組件和技術幾乎均可以在Linux平臺上找到免費、穩定並且高性能的東東，若是是Windows平臺，你須要祈禱微軟趕快開發出來

6. 在虛擬化的今天，一臺高性能服務器能夠跑十幾臺虛擬機，用Linux，你獲得的是免費、穩定的虛擬機，用Windows，你一臺服務器的受權費將 x N。

總之，立志作大型互聯網應用的企業，絕對絕對絕對不能夠用Windows Server作平臺。

京東一開始估計招了會.Net的人，開發效率高不意味運營效率高，一開始大方向錯了，越日後越難改。

＝＝ 補充一點 ＝＝

不 是不看好.Net語言自己，而是這是Windows Server和Linux平臺的對決，要先選對平臺，再考慮具體用什麼語言開發。平臺選錯了，不管你怎麼努力，都不可能最終成功，由於Windows不是 你控制的，你也沒法修改Windows，而全世界最優秀的開發人員天天都在爲Linux添磚加瓦。

作互聯網要拋棄大企業那種IT外包／「給微軟OracleIBM付費便可作好IT服務」的思想，一切均要靠本身！

================================================

 

很是認同這句：作互聯網要擯棄大企業那種it外包的思想，一切均要靠本身！

 

互聯網應用。若是網站用戶數很大扛不住了，若是遇到瓶頸了，這種多是廠商都沒遇到過的(比阿里巴巴之類的應用就是)，由於廠商儘管說是支持多大性能，可是缺少互聯網大規模實際檢驗的測驗。當oracle、微軟無法給你解決問題這些問題的時候。這個時候就必須得創造技術，或者修改源代碼來符合本身業務須要(一個封閉系統源代碼封閉起來你控制，必須祈禱於微軟等廠商來給你解決)。傳統軟件開發領域電信、銀行業的人哪怕有10年20年的經驗，他的經驗放到互聯網有時候是錯誤的。這個存儲過程封裝業務邏輯也是同樣的。在電信大企業都是這樣子用。到了互聯網，這樣子用，我以爲就是坑。

 語言的選擇本質就是平臺的選擇：http://dbanotes.net/review/choose_programming_languages_important.html

 

 

 

 

 

 

本篇文章有感而發，我一直以爲，專攻方向不一樣，經驗則是不一樣的。不是說作了10年8年，而後放到互聯網就通用。我很是確定一點，在互聯網環境下更多就是靠web層來計算，靠緩存和分佈式來應對大流量訪問，而不是像銀行業那樣子大手筆花錢購買商業數據庫系統(如oracle)和幾十萬到幾百萬一臺的小型機來提升性能。他們綁定死依賴死某個具體的數據庫不要緊，他們要的數據安全，出了問題能夠找廠商負責。況且他們也也不差錢吧。當你在電信作了10年開發，把這種存儲過程實現業務邏輯的經驗放到互聯網，不必定是什麼滔天大罪的事情，但我以爲就是一個坑，將來埋下的坑。

 

我以爲，具有本身的獨立思考能力很是重要。不能被別人的10年20年開發經驗影響而所放棄獨立的思考，就像受到工商銀行的技術總監頭銜所影響的那樣子。金融、電信、銀行業那套經驗不用移植過來。