oracle中不包含怎么写_为什么不建议把业务逻辑写在sql中？

最近小编的项目中存在很多复杂的sql,这些sql写在Mybatis的Dao.xml文件中。这些其中包含复杂的查询，新增，修改的逻辑，有的被begin end包含起来形成了一个处理多个逻辑的sql代码片段，读起来真是大费脑筋。

原则上来讲，数据库最好处理简单的存数和取数的逻辑，不建议作为一个业务逻辑处理地方。存储过程导致了业务代码的逻辑既分散在数据库中，又分散在中台的java代码中，给项目的维护带来的巨大的成本。

虽然在sql中处理业务简单直接，开发起来省事，但是当项目切换其他类型的数据库时，修改的成本是巨大的。尤其是带有特性的函数，处理方式的迁移，需要修改的地方太多了，有的甚至要重新编写。比如Oracle的pivot在pg数据库中不能使用，只能改成case when 这种方式。

写在xml中的sql可读性往往很差，夹杂着各种条件，整个业务逻辑处理既分散在java中，也分散在sql中，阅读起来往往要切换文件，可读性和可维护性很差。

把业务逻辑写在sql中，导致数据库的读写和处理占用内存过高，吞吐量下降，作为单体的数据库难以对接多台中台服务器，导致整个中台卡慢。当把业务逻辑写在java代码中，作为微服务的方式可以很方便扩充中台服务器，提高性能。

简单干净的sql有利于降低数据库开发的出错率，集中业务逻辑于java代码中，有利于与持久层的解耦，有利于开发与维护。