Java Web开发中,业务逻辑写在SQL里好还是代码里好呢？有什么建议吗？

文章插图
在C/S时代很多逻辑的实现都是通过SQL来实现的。主要原因是业务规模和部署方式决定的。早期的C/S编程时代往往都是非分布式环境下的开发。而且大多数情况下并不需要考虑移植性问题。此时采用SQL来完成业务逻辑是比较方便的处理方式。
采用存储过程来完成业务逻辑最大的好处是性能会比较好。但是这也取决于业务规模的大小。如果业务规模过大。那么性能会下降的比较厉害。而早期的数据存储规模比较小。所以采用存储过程的方式是比较方便的。
目前的Web开发已经到了大数据时代、云计算时代。业务类型和业务规模都有了较大的变化。尤其是大数据时代下NoSql数据库的广泛采用。使用SQL语句来完成业务逻辑的情景就更少了。而且。目前的程序大部分都是分布式方式。采用Sql存储过程的方式来处理业务逻辑会非常麻烦。而且会导致整个项目的移植性和可读性都严重下降。
目前在传统企业的开发团队中采用Sql来处理业务逻辑的情况比较常见。因为大部分传统企业的数据库还依然是关系型数据库。而且不存在移植性要求。这种固定场景下的开发是完全可以使用Sql来处理业务逻辑的。未来使用Sql处理业务逻辑的情况也有一定的应用场景。所以学习存储过程的编写还是有一定必要的。
我的研究方向是大数据和人工智能。目前也在带大数据方向的研究生。我会陆续在头条上写一些关于大数据方面的文章。感兴趣的朋友可以关注我的头条号。相信一定会有所收获。
如果有大数据方面的问题。也可以咨询我。
谢谢！
其他观点：
个人建议。普通的业务逻辑尽量写在后台代码中。尽量避免写在SQL中。并且尽量避免使用存储过程。

文章插图
【Java Web开发中,业务逻辑写在SQL里好还是代码里好呢？有什么建议吗？】不可否认将业务逻辑写在SQL或存储过程中。也是有这种做法的优点。比如：可以减少网络交互的成本。原本后台程序需要多次访问数据库。现在可以用复杂的SQL或者存储过程封装好。然后程序调用一次即可。
但是复杂SQL和存储过程也有很大的缺点：
不可移植性。每种数据库的语法多多少少都会有一些差异；如果SQL中使用到数据的一些函数、方法。而这些又是该数据独有的。那么很难做数据库的迁移。
业务逻辑会存在SQL和程序中。这种业务逻辑多处存在。会让后期的系统维护和调试都变得更加困难。
数据库中所支持的函数及语法不一定可以满足所有的需求。相比来说。编程语言中的功能更加的强大。
如果SQL、存储过程中有复杂的计算。也会增加数据库机器的压力；并且很难做到分布式部署。
相比编程语言。业务逻辑写在SQL、存储过程中。很难做到业务逻辑的抽象。所以从代码复用的角度来看。编程语言更胜一筹。