许多大型数据库在运行多年后都会积累出很多的数据表，严重者数以万计，非常臃肿。这些数据表年代久远，有些已经忘记建设原因，也可能已不再有用，但因为很难确认而不敢删除。这给运维工作带来巨大的负担。伴随着这些表还有大量的存储过程仍在不断地向这些表更新数据，占用计算资源，经常要迫使数据库扩容。
这些表是真地是业务需要的？业务会复杂到需要成千上万的表才能描述吗？
有过开发经验的人都知道这不大可能，几百个表就能描述相当复杂的业务了。这些表大多数都是所谓的中间表，并不是用来存储基础数据的。

那么，为什么会有中间表？
中间表大多是为数据呈现（报表或查询）服务的。原始数据量很大或计算过程很复杂时，直接计算很麻烦且性能很差，我们就会先计算出一些中间结果存起来，呈现时再根据参数做一些简单过滤汇总计算，用户体验就会好很多。这些中间数据就会以数据表的形式出现，同时也会伴随着存储过程去定时更新数据。前端报表是稳定性很差的业务，要经常修改和增加，随之而生的中间表也就越来越多。
还有一些中间表是外部数据源造成的，有时应用要把库外数据导入到数据库后才能和库内数据混合计算，这也会让数据库多一些表。而且，很多外部数据是多层的 json 格式，在关系数据库中还要建立多个关联的表来存储，会进一步加剧中间表过多的问题。

之所以要把中间数据放进数据库，主要是为了获得数据库的计算能力。数据库外缺乏强有力的计算能力，而数据库的计算能力是封闭的（它不能计算数据库外的数据）。为了获得数据库的计算能力，只能把这些数据装入数据库，形成了中间表。
数据库还有两个工程结构上的原因会成为这件事的帮凶：
数据库是个独立进程，计算能力在应用外部，不从属于某个应用。各个应用共享数据库，都能访问数据库。某个应用中生成的中间表可能被另一个应用引用，这就造成了应用间的耦合性，即使某个中间表的制造者已经下线不用，但因为可能被别的应用使用了而不能删除，中间表就会一直留下来。
数据库表以线性形式组织管理的。在数量不多时尚可，太多（几千上万时）就很混乱，人们一般会用树状结构来组织管理众多的条目。但关系数据库不支持这种方案（它的模式概念可理解为只能分两层），这就要给表起较长的名字来分类，这一方面使用不便，另一方面对开发管理水平要求很高，在工作较急迫时就顾不上规范了，上线了也就忘了，A 业务搞几十个，B 业务弄几十个，时间一长，就会遗留大量的中间表。
中间表及相关的存储过程占用大量昂贵的数据存储及计算资源，显然，在经济上很不划算。

如果能够实现独立计算引擎，使计算不再依赖于数据库提供，那么就可以为数据库瘦身了。
这就是 esProc SPL 了。
esProc SPL 拥有开放和可集成的计算能力。开放性是指计算能力与存储分离，计算不依赖于存储，也就是存算分离。否则，如果要求特定的存储方案，只是把数据库的臃肿换了一个地方臃肿。可集成性是指计算能力可以嵌入到应用程序中，成为应用的一部分，而不能象数据库那样是个独立的进程，这样就不会被其它应用（模块）共享，避免出现应用间的耦合问题。

中间数据不必再以数据表的形式落在数据库中，而可以放到文件系统中，由 SPL 提供计算能力。对于只读的中间数据，使用文件存储时不必考虑改写以及相应的事务一致性问题，机制大为简化，这样能获得比数据库更好的性能。文件系统还可以采用树形组织方案，将各个应用（模块）的中间数据分类管理好，使用也更方便，这样中间数据就会天然从属于某个应用模块，不会被其它应用访问到。当有应用修改或下线时，相应的中间数据可以跟随修改删除，而不必担心被共享而产生的耦合问题。用于生成中间数据的存储过程也可以移到数据库外部，作为应用程序的一部分，同样不会产生耦合问题。

SPL 提供了高性能二进制文件格式，采用了压缩、列存、索引等机制，还支持并行分段，以及相关的高性能算法，进一步提升计算的性能。
SPL 还可以直接实现库外数据与库内数据的混合计算，外部数据源不必再导入数据库。临时取数有更好的实时性，而且，还能充分利用原数据源的优势，这些我们在多源混合计算时已经讲过。

有了 esProc SPL 开放且可集成的计算能力，在设计应用的体系结构时就会更为得心应手，计算可以放在最合适的位置，不必为了获得计算能力而部署多余的数据库，让数据库专心做它最合适的事，复杂的灵活的计算都丢给 SPL 解决，将资源效用发挥到最大。

最后，esProc SPL 在这里 https://github.com/SPLWare/esProc 。