事情起因於羣裏轉發一篇文章《爲什麼阿里巴巴禁止使用存儲過程？》
作者用自己的親身經歷講解存儲過程維護的不方便。
然後大家討論存儲過程的優勢和缺點。
引子：存儲過程
大白：存儲過程在很多場景時有其優勢，比如性能。但對於業務邏輯的通用方法，非常不推薦將其寫在存儲過程中，代碼複用、擴展與客戶端語言比，相差甚遠。也許終究能實現，但代價與風險比客戶端語言要高，得不償失。
花也花不完：我的想法是可以用，分場景
如果應用的當，省時省力
我用的比較多
主要是性能是第一，依據自身去控制
Steven:用起來，比較難控制，把握度
曾經在做ERP的時候把整個計劃翻單用存儲過程實現
然後沒有人能改，牽扯表太多，邏輯有太複雜，那時候有些炫SQL的感覺，現在想來比較坑人
後來項目，部長禁止存儲過程
康利山：現在很多公司， 是一刀切， 不讓用不是說這個東西不好， 只是大家場景可能用不熟導致安全問題
Steven：如果人員變化比較頻繁，存儲過程的確會增加業務理解時間，相對於犧牲些速度，也不是很在意了吧。寫不好，速度反而更慢。寫得好，自然是省事、省力
花也花不完:
不是這樣你們是要性能還是要可讀，想好
存儲過程，對他限制，一定是沒有能力去駕馭
不能怪存儲過程
一個存儲過程4000多行代碼，我寫過，解決了20TB數據的處理時間有原來8小時壓縮到7分鐘處理好
存儲過程是一個雙向的，關鍵是看你怎麼去用好和管理好，性能是一個坎
場景：低延遲
kimmking：高效低延遲，一定是數據和計算放到一起，遠古時代是存儲過程。現代則是redis+lua，voltdb/hazelcast+java這種。我們叫 數據親密性 data affinity。
看你要啥，一般情況，確實沒必要用存儲過程
存儲過程，即不好編寫，也不好調試，不適合大規模的業務系統協作開發
早期像銀行核心的業務就沒幾個人懂，都是年紀大的老專家（中醫，劃掉），他們寫好存儲過程，外面用什麼東西封裝起來，變成指令，給前置系統調用就成了。這樣，核心是穩定的，業務也是二十年不變的。
現在的互聯網，上午定的需求，下午就不行了，你得敏捷。
花也花不完：找我，我可以玩轉它
kimmking：哈，，，所以，企業需要的不是一個能搞定它的專家，而是一幫搬磚的，也能一起幹活。
這叫軟件開發的分佈式。
就像我們用廉價pc的集羣，去代替小機，mainframe，高端存儲。
smith :
深度綁定了oracle 要換其他數據庫很難
kimmking:
一樣，我第一份工作是用的db2
10來年前，每年license2000-3000萬，單位一旦過幾年培養了一批db2專家，就直接去了IBM的DB2團隊。
康利山：這差距也太大了吧
kimmking:
可以預期，存儲過程裏，可以用cursor一點點往前走，又拋去了網絡開銷
花也花不完:
有一種東西交工具化，我不相信人可以一直堅持下去，讓程序去做吧，該放手了
kimmking: 肯定在數據量大的時候，會快。
也是工具化，只是工具不同，
一般企業級開發，提倡快速開發框架RDP，半成品的腳手架之類的
花也花不完:
有空了，我們聊聊，我給你看看黑科技
kimmking:
說個關鍵詞看看
vonneumann:
很多現代工程實踐和設計理念確實沒法做在存儲過程裏 太難管理了
kimmking:
我一直搞核心系統，低延遲交易我比較關注，這一塊的黑科技，大概就是SPDK，RDMA，PM之類的
繞過操作系統通信，硬件加速，持久化內存。
花也花不完:
不知道怎麼說了，就像c++一樣，沒有幾人能玩轉了
花也花不完:
在說存儲過程好，估計有人要打我了
韓錚 vonneumann:
說極限場景意義不大哈 畢竟不是單打獨鬥 有幾個人能用存儲過程搞70倍性能優化
具體的幾個技術
kimmking:
redis支持lua，大家知道吧
redis看做數據庫，然後做點簡單的計算，丟一段lua腳本給redis server，他算完了給你結果。
避免了大量的trip round
hazelcast，內存網格，支持動態的給一些類，同步到內存數據節點，計算完了給你結果，可以分佈式的做聚合
voltdb更牛逼了，內存+關係數據庫，作者是圖靈獎獲得者，數據庫領域宗師，直接支持用java寫“存儲過程”
花也花不完:
接近內核運算
田浩沛:
8小時這麼快？以前SAP有個系統出報表要7天，客戶居然習慣的
kimmking:
我們去年上半年系統的調研和POC過，voltdb真心nb
花也花不完:
越貼進內核運算，是越好的，其它的就是概念
kimmking:
綁定cpu，cache對齊
低延遲的核心要素就是，離cpu能有多近就多近，離io能有多遠就多遠
vonneumann:
存儲過程不是不好 是太容易被誤用