让业务实现回归数据库

      让时间回到2000年，当年流行的MIS系统绝大多数均采用C/S架构，也就是使用PowerBuilder/Delphi/VB等工具开发的胖客户端通过OCI或其他接口直接连接Oracle或其他数据库，业务逻辑在数据库端实现，也就是通过PL/SQL、T-SQL语言等实现存储过程、函数、触发器等，由胖客户端进行调用。C/S架构，其中一个很大的问题是不利于扩展，由于Client直接连接数据库，在业务繁忙的时候很容易把数据库端的资源（连接数、服务器内存等）耗尽，导致业务中断甚至无法办理。

       为了解决这个问题，在C/S之间多加一层，同时把C端换成B端，也就是多加了一层中间层，同时把胖客户端换成了瘦客户端如浏览器等。数据库连接由中间层进行管理，原来由存储过程实现的业务逻辑改由中间层实现，这样的做法让不少的服务端语言（最著名的莫过于Java）得到了广泛的推广和应用。B/S/S的架构，让数据库的角色沦为了数据存储器（Data Container）的角色，外加一些增删改查的逻辑。随着数据量的不断增长，中间层与数据库端的交互越来越频繁，数据处理的低效与用户希望快速高效的获得结果的诉求之间矛盾显得尤为突出。首先，数据从数据库端传送到中间层需要耗费时间；其次，使用中间层开发语言（大多数使用Java）处理大批量数据时，效率相对C/C++低效得多（尤其在系统资源利用上）；再次，处理完毕后如果还需要入库，还需要一次网络的传输。如何解决这个问题？让业务实现回归数据库是行之有效的一种解决方法。

      让业务实现回归数据库，并不是意味着业务应用系统的开发要采用原有的C/S架构，而是在三层结构的基础上，把部分业务逻辑的实现（尤其是需要频繁数据交互和数据处理的地方）回到数据库端实现，这时候可以使用C/C++这类高效的语言进行数据库的扩展开发，在数据库服务器端对大批量数据进行处理或分析，减少网络的来回传输，提高系统的整体效率。

      数据库的应用系统业务逻辑如何高效实现？如果是Oracle/SQLServer的话，存储过程不失为一个很好的选项，虽然这个选项让人觉得很Low和倒行逆施、不合潮流，但却是一个有效和高效的选项，特别是在以Oracle为中心的应用场景下。如果是PostgreSQL的话，除了存储过程，还可以开发Extension，用C/C++、Python、Java甚至JS都可以，当然，效率最高的莫过于C语言。

      与其在中间层上耗费大量的资源还不如在后台数据库上投入资源，形成数据库集群，在分布式数据库的应用环境下，每个节点即时数据存储节点也同样是计算节点，简单有效且高效。