二十年前，华为的一个项目组为了实现应用与数据库无关，对应用进行改造的时候去掉了所有的存储过程，上线后发现改造后的应用性能下降十分严重。我帮助分析后发现因为数据库与应用模块跨数据中心部署，因此SQL在网络上的交互延时严重影响了性能。因此在当时的条件下，他们很难放弃存储过程，为此他们最终放弃了多数据库支持而选择了回归存储过程。
这些年随着互联网企业在IT上的成功，很多企业也在学习互联网架构。大量的应用不再使用存储过程，应用的业务逻辑更多地被从数据库中抽取出来，放到应用系统中。应用对数据库的依赖就降低了，应用在不同品种的数据库之中的迁移也变得简单了。同时因为业务逻辑更多地迁移到应用服务器上，数据库服务器的资源消耗也下降了，数据库服务器的瓶颈也得到了缓解。于是这些年应用去存储过程在很多企业里热门起来，存储过程的使用也大幅下降了。
不过也有一些企业发现，去掉存储过程，将业务逻辑放到应用中去之后，应用的质量管控变得更加困难了。以前在一个研发队伍中开发存储过程的都是对业务逻辑理解十分深刻，数据库功底比较好的老鸟，这些人写出的存储过程虽然复杂，不过质量还是杠杠的。哪怕存在一些问题，优化起来只要集中精力去优化PL/SQL的代码就可以了。而现在业务逻辑分散到应用中，由水平差异较大的开发人员去开发，应用的质量变得更难控制了，优化的难度也变大了。
实际上绝大多数传统行业企业是缺乏互联网基因的，互联网企业与传统企业最大的区别是在IT上的投入的区别。互联网企业能把所有逻辑放到应用上，并不是互联网企业的架构有多优秀，而是互联网企业能够在IT上投入巨资，由大量优秀的开发人员来完成这项工作。而传统行业企业的IT投入与互联网企业无法相比，IT员工工资收入要低得多，IT部门人员的素质肯定也要远远低于互联网企业。在这种情况下，研发团队往往是很难驾驭好互联网架构的应用的。
企业级关系型数据库都有存储过程这个功能，这个功能就是为了简化应用开发难度，提高应用效率的。在应用中使用存储过程是可以降低应用软件开发与维护成本，提高系统中批量处理业务的性能的。近来企业应用中使用较少除了受到互联网企业的引导之外，还有一个因素是减少对某个数据库的依赖。其实在前些年去IOE的过程中，很多企业已经感受到了数据库迁移带来的痛苦，以及被Oracle数据库绑定后不断上升的数据库使用成本的困扰。
当年很多企业决定借鉴互联网架构的另外一个原因是因为很多应用开发以数据库为核心，而数据库在横向扩展方面的能力不足，因此数据库往往会成为应用系统中最大的瓶颈。与其扩容昂贵的小型机，还不如将部分应用负载转移到相对便宜、比较容易横向扩展的应用服务器上。
有些企业在应用架构转型中获得了成功，不过很多企业转型后虽然解决了数据库服务器瓶颈的问题，但是遇到了新的挑战-应用开发的成本太高了。与传统的IOE架构相比，现在的应用架构中引入了太多复杂的组件，应用开发成本增大，开发周期变长，运维难度也大幅上升。有些企业甚至已经在反思是不是每个系统都需要采用如此复杂的架构。
在数据库国产化替代的今天，我看到了一个十分有趣的现象，那就是国产数据库大多数都提供了比较好的Oracle PL/SQL的兼容支持。而且大多数国产数据库支持的PL/SQL语法肯定都不全面，不过因为PL/SQL中较为容易实现的部分都被国产数据库所支持了，所以目前国产数据库的PL/SQL语法反而是比较接近的。在国产数据库之间迁移PL/SQL存储过程的难度很低。使用国产数据库后，如果想要换另外一个国产数据库，基本上可以平替。
前几天和一个国产数据库厂商谈到这方面的问题的时候，突然想到，国产数据库时代，是不是可以回归大量使用存储过程，从而降低应用研发与应用维护的成本呢？似乎这是可行的，当年JAVA刚刚流行，替代C的时候就是如此。因为存储过程这个大杀器的存在，让企业使用熟悉业务逻辑与数据库架构的高手将核心业务逻辑封装在存储过程中，再安排大量技术水平一般的JAVA程序员去解决前端应用易用性的问题，从而让信息系统开发的门槛一下子降低了几个数量级。
已经脱离开发多年了，不太清楚目前应用架构师关注的是什么。我做应用架构师的时候，总是在追求化繁为简，尽可能让一线开发人员变成工具人，而似乎现在的风向有些变化，应用开发已经变得相当复杂了。而让部分企业级应用回归到以数据库为核心，对于国产数据库而言也是一个巨大的挑战，只有国产数据库真的能打了，这个愿望才能实现。不过对于企业级应用而言，适当回归存储过程的使用，可能能够解决目前的一些问题。
今天就聊到这里吧，明天我们来分析分析，国产数据库的PL/SQL兼容能力，需要在哪些地方发力，或者说用户选型数据库的时候从哪些角度来看存储过程的兼容性。
