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

试试语音读文章

热门回答：

在C/S时代很多逻辑的实现都是通过SQL来实现的。主要原因是业务规模和部署方式决定的。早期的C/S编程时代往往都是非分布式环境下的开发。而且大多数情况下并不需要考虑移植性问题。此时采用SQL来完成业务逻辑是比较方便的处理方式。

采用存储过程来完成业务逻辑最大的好处是性能会比较好。但是这也取决于业务规模的大小。如果业务规模过大。那么性能会下降的比较厉害。而早期的数据存储规模比较小。所以采用存储过程的方式是比较方便的。

目前的Web开发已经到了大数据时代、云计算时代。业务类型和业务规模都有了较大的变化。尤其是大数据时代下NoSql数据库的广泛采用。使用SQL语句来完成业务逻辑的情景就更少了。而且。目前的程序大部分都是分布式方式。采用Sql存储过程的方式来处理业务逻辑会非常麻烦。而且会导致整个项目的移植性和可读性都严重下降。

目前在传统企业的开发团队中采用Sql来处理业务逻辑的情况比较常见。因为大部分传统企业的数据库还依然是关系型数据库。而且不存在移植性要求。这种固定场景下的开发是完全可以使用Sql来处理业务逻辑的。未来使用Sql处理业务逻辑的情况也有一定的应用场景。所以学习存储过程的编写还是有一定必要的。

我的研究方向是大数据和人工智能。目前也在带大数据方向的研究生。我会陆续在头条上写一些关于大数据方面的文章。感兴趣的朋友可以关注我的头条号。相信一定会有所收获。

如果有大数据方面的问题。也可以咨询我。

谢谢！

其他观点：

个人建议。普通的业务逻辑尽量写在后台代码中。尽量避免写在SQL中。并且尽量避免使用存储过程。

不可否认将业务逻辑写在SQL或存储过程中。也是有这种做法的优点。比如：可以减少网络交互的成本。原本后台程序需要多次访问数据库。现在可以用复杂的SQL或者存储过程封装好。然后程序调用一次即可。

但是复杂SQL和存储过程也有很大的缺点：

不可移植性。每种数据库的语法多多少少都会有一些差异；如果SQL中使用到数据的一些函数、方法。而这些又是该数据独有的。那么很难做数据库的迁移。

业务逻辑会存在SQL和程序中。这种业务逻辑多处存在。会让后期的系统维护和调试都变得更加困难。

数据库中所支持的函数及语法不一定可以满足所有的需求。相比来说。编程语言中的功能更加的强大。

如果SQL、存储过程中有复杂的计算。也会增加数据库机器的压力；并且很难做到分布式部署。

相比编程语言。业务逻辑写在SQL、存储过程中。很难做到业务逻辑的抽象。所以从代码复用的角度来看。编程语言更胜一筹。

所以。普通业务逻辑尽量不要使用复杂SQL或存储过程。而如果是报表统计或者ETL抽取等功能。可以根据实际的情况。采用复杂SQL或者存储过程来处理。

我将持续分享Java开发、架构设计、程序员职业发展等方面的见解。希望能得到你的关注。

其他观点：

根据项目组的特点来。

如果团队健康。写在代码中。

如果团队不健康。大部分是刚参加工作的。那就写在sql中。经验者维护。

• 准备与好友合伙做生意,开什么店合适？
• 想开个店,开什么好呢？资金不多,刚刚创业。谢谢？
• 有什么行业适用于初创业？
• 刚入社会的人想开店,最好开一家什么店？
• 什么类型的项目适合刚创业的人群呢？

以上就是由互联网推广工程师 网创网 整理编辑的，如果觉得有帮助欢迎收藏转发~