讨论：应不该该用存储过程？
事情原由于群里转发一篇文章《为何阿里巴巴禁止使用存储过程？》java
做者用本身的亲身经历讲解存储过程维护的不方便。c++
而后你们讨论存储过程的优点和缺点。redis
引子：存储过程
大白：存储过程在不少场景时有其优点，好比性能。但对于业务逻辑的通用方法，很是不推荐将其写在存储过程当中，代码复用、扩展与客户端语言比，相差甚远。也许终究能实现，但代价与风险比客户端语言要高，得不偿失。数据库
花也花不完：个人想法是能够用，分场景安全
若是应用的当，省时省力性能优化
我用的比较多网络
主要是性能是第一，依据自身去控制oracle
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:
存储过程不是很差 是太容易被误用