关于白鳝存储过程技术话题

http://mp.weixin.qq.com/s?__biz=MzA5MzQxNjk1NQ==&mid=2647853188&idx=1&sn=24be22393486f86b00963a6ad6c314ff&chksm=88799410bf0e1d0640ccca80d66afb4c40a7265a643153a5a37e0437d0cf303abd64939491af&scene=21#wechat_redirect

老白关于存储过程的使用新闻如上. 存储过程这老古董了.在我的ORACLE优化建议来说,是不提倡的!  虽然我也是老DBA, 以前做过C/S架构的DELPHI开发工程师,后来转数据库开发工程师,再后来转ORACLE DBA,现在是MYSQL DBA.
什么是存储过程? 它就是过程化处理SQL语句的单元. 当初主要是在C/S架构的时候,客户端PC机都是586,运算能力差,网络也是100兆局域网. 把数据拉到PC机进行运算是不太合理的,跑起来非常慢,大量的数据从数据库服务器传给PC机上,极大的占用了网络带宽. 所以把业务放在数据库服务器上跑,存储过程,触发器,外键,约束等技术都用上了.
随着PC的进步,和互联网的到来,从上次C/S架构 在2005年后演化成了B/S架构.

这里先给大家介绍下架构, 在很兆兆以前,你出生之前,80年时代数据库就来了中国,是基于DOS界面的XXBASE. 这个时候叫单服务器架构(S). 来到了90年代,WINDOWS 95大流行, 基于WINDOWS平台开发出来的MIS ERP系统.用PC跑界面,大部分用VB和DELPHI开发,虽然也有JAVA,不过很少一部分. 这个时候叫C/S架构  客户机/服务器.  按如今的话来说客户机(PC)基本叫前端,处理用户输入输出,数据展现.核心业务还是在数据库服务器上跑.这个时候流行的数据库有DB2,ORACLE,MS SQLSERVER. 在下只接触了MS SQLSERVER. 并在2005年给深圳证券交易所,做个什么信息发布系统.也是C/S架构.才接触ORACLE. 当时测试小妹在联合广场B栋,惊讶地说ORACLE安装介质需要2GB大!  换算今天的说法TMD ORACLE安装介质要2TB大.

接下来是B/S架构. 互联网的到来 90年代已经到. B是浏览器,S是服务器.
也许这S 是指应用服务器.比如说TOMCAT和重量级,企业级WEBLOGIC.
这个时候基于企业级开发的JAVA开始上台表演了. 这个时候我去面试,就被问到如何看待存储过程, 也就是说业务逻辑是在存储过程上实现,还是在JAVA应用端实现. 我给出个比较现实的回答. 是基于数据流大小为标准.如果大,就用存储过程.如过小就放在应用端. 估计面试官是JAVA工程师,偏向应用端吧. 对我的回答估计不满意.  不过JAVA在21世纪初走过了弯路. 开始想一统天下,用EJB ORM直接走上面向对象纯粹道路. 记得那时候DELPHI与JAVA 之争在深圳一家电力公司上演了.两个项目经理还上演武斗! 不过JAVA被落选了,JAVA项目给客户上去跑得贼慢,上的是小型机. JAVA+EJB+ORACLE组合. 而DELPHI项目使用 DELPHI+COM+SQL SERVER. 这个时候听说搞JAVA能拿到7K,而DELPHI才拿到3.5K. 导致我一直想学JAVA.

2010年后 JAVA放弃了EJB 转向轻量级的SSH架构.才在企业级开发站住了脚, 不过SSH架构太难学了,要配置一大堆.用JAVA代码去画界面,在代码里输出JSP代码. SSH架构 前面的S和后面的H两个架构导致性能不佳! 开发成本很高! 这个时候宝兰公司OVER了,大量人才跳到了微软,搞出个NET开发框架. 要重新学习NET语言,哎! 我只好转数据库开发.就是写存储过程.

后来几年数据库开发工作越来越少,只好转向了数据库管理工作. 2015年什么互联网+,大流行,也就是移动互联网的到来,带来了大量的用户.对并发要求越来越高,高速发展中敏捷开发,DEVOPS. 导致了单体服务转微服务阶段.
SSH架构/SSM架构 转向了 前后端分离 VUE+Spring+M. 对数据库要求转向了分布式.

C/S架构 数据库主要是 备份+主从  (MS SQLSERV,ORACLE)
B/S架构 数据库主要是主从+RAC    (ORACLE)
B/S+架构 数据库主要是主从+分布式 (MYSQL)

说到这里,写了一大堆与存储过程无关的故事和历史. 其实就是告诉大家,存储过程被淘汰有12年之久.也不能说是完全淘汰,它只存在极小范围存活着.也就是稳定要求高的ERP系统.或者数据库仓库.

国产数据库回归存储过程,并不代表存储过程的复活成为大趋势,大流行.
国产数据库回归集中式和存储过程,不过只是满足C/S架构下的市场而已.

再说了存储过程并不能降低,应用开发成本,反而增加开发成本. 这一点才是我写文驳白鳝的核心!  存储过程精妙和优化需要老的数据库开发工程师到位.市场比较难招了. 培养应用开发工程师去写存储过程,也需要成本和试错成本. 何必呢? 应用开发工程师只要懂SQL 99  CURD就OK. 把精力放在业务实现上.关于JAVA不要写成了屎山代码就不错了.

既然要动应用,为何还是要把业务放在存储过程里,不直接放在应用端里?
国产数据库回归现实,在不修改应用情况下,和平替代ORACLE.自然ORACLE的存储过程也要替代,兼容PL/SQL也是不在话下的. 重点就是不修改应用代码情况下,记住这个前提才是重点.

如今应用开发成本上去,下不来,关键不在数据库上. 用存储过程可以大幅降低,感觉不靠谱. 明显是微服务太微了.一个项目做成300个微服务.需要600多台PC服务器.而数据库顶多5-6台而已. 如今微服务回归单体使用DDD设计思想.极大减少成本!

之所以搞出微服务来,并不是说单体VUE+SRPING+MYBAITS 性能不高,并发能力低. 单体完全用负载均衡软件横向扩展应用服务器. 微服务主要是能快速上线的要求. DEVOPS,敏捷开发.自动构建,自动测试! 这一整套概念就是为了解决快速上线的需求.
目前经济下行,互联网业务饱和了,都喊降本增效.对快速上线要求没有那么高了.
要么回归到单体服务,要么减少微服务数量和层次.才是降低应用开发成本关键!

而不是像白鳝说的存储过程可以降低应用开发成本,基于PL/SQL语法的存储过程会大行其道.

对DBA来说,混国企市场的DBA来说学习PL/SQL语法的存储过程还是有些必要的. 

喊了那么久的存算分离, 各大数据库新概念 存算分离,HATP,分布式,AI.
其中存算分离,不应该是SQL路由,编译,优化这样的算. 而应该是指业务和数据分离. 既然前后端都分离了,那么业务和数据也要分离! 

那种白鳝举的列子,跨网络(多机房,互联网)数据访问,那是自然很慢! 毕竟这种案例非常少! 大部分业务都是前端,应用和数据库都同在一个机房. 哪怕是多机房,多中心也是一整套地部署. 数据库端通过光纤主从同步,RAC同步!
 

写作不易,麻烦点广告,或者分享到朋友圈中!
 

以上是本仙纯技术话题, 不涉及那个啥,别妄想,我没有,别乱说
不支持读者的任何抽象行为，阅读本文产生的任何后果，作者概不负责

设计AB表