目前大部分研发团队都要求业务逻辑用代码来实现，SQL操作往往都是基本操作。用SQL来表现业务逻辑，也就是通过存储过程的方式来表现业务逻辑是比较传统的开发方案。
在C/S时代很多逻辑的实现都是通过SQL来实现的，主要原因是业务规模和部署方式决定的。早期的C/S编程时代往往都是非分布式环境下的开发，而且大多数情况下并不需要考虑移植性问题，此时采用SQL来完成业务逻辑是比较方便的处理方式。
采用存储过程来完成业务逻辑最大的好处是性能会比较好，但是这也取决于业务规模的大小，如果业务规模过大，那么性能会下降的比较厉害。而早期的数据存储规模比较小，所以采用存储过程的方式是比较方便的。
目前的Web开发已经到了大数据时代、云计算时代，业务类型和业务规模都有了较大的变化，尤其是大数据时代下NoSql数据库的广泛采用，使用SQL语句来完成业务逻辑的情景就更少了。而且，目前的程序大部分都是分布式方式，采用Sql存储过程的方式来处理业务逻辑会非常麻烦，而且会导致整个项目的移植性和可读性都严重下降。
目前在传统企业的开发团队中采用Sql来处理业务逻辑的情况比较常见，因为大部分传统企业的数据库还依然是关系型数据库，而且不存在移植性要求，这种固定场景下的开发是完全可以使用Sql来处理业务逻辑的。未来使用Sql处理业务逻辑的情况也有一定的应用场景，所以学习存储过程的编写还是有一定必要的。
我的研究方向是大数据和人工智能，目前也在带大数据方向的研究生，我会陆续在头条上写一些关于大数据方面的文章，感兴趣的朋友可以关注我的头条号，相信一定会有所收获。
如果有大数据方面的问题，也可以咨询我。
谢谢！
评论0
加载中...
个人建议，普通的业务逻辑尽量写在后台代码中，尽量避免写在SQL中，并且尽量避免使用存储过程。
不可否认将业务逻辑写在SQL或存储过程中，也是有这种做法的优点，比如：可以减少网络交互的成本，原本后台程序需要多次访问数据库，现在可以用复杂的SQL或者存储过程封装好，然后程序调用一次即可。
但是复杂SQL和存储过程也有很大的缺点：
不可移植性，每种数据库的语法多多少少都会有一些差异；如果SQL中使用到数据的一些函数、方法，而这些又是该数据独有的，那么很难做数据库的迁移。
业务逻辑会存在SQL和程序中，这种业务逻辑多处存在，会让后期的系统维护和调试都变得更加困难。
数据库中所支持的函数及语法不一定可以满足所有的需求，相比来说，编程语言中的功能更加的强大。
如果SQL、存储过程中有复杂的计算，也会增加数据库机器的压力；并且很难做到分布式部署。
相比编程语言，业务逻辑写在SQL、存储过程中，很难做到业务逻辑的抽象，所以从代码复用的角度来看，编程语言更胜一筹。
所以，普通业务逻辑尽量不要使用复杂SQL或存储过程，而如果是报表统计或者ETL抽取等功能，可以根据实际的情况，采用复杂SQL或者存储过程来处理。
评论0
加载中...
根据项目组的特点来。
如果团队健康，写在代码中。
如果团队不健康，大部分是刚参加工作的，那就写在sql中，经验者维护。
评论0
加载中...
早期CS架构开发，主要针对企业应用，S端就是数据库端，那时几乎所有的业务都是在存储过程中完成，为什么？因为数据库服务器足够强劲，动辄上千万的小型机，想想那时候Oracle的风光。
但随着web的兴起，BS开发架构逐渐成为主流，这里的S已经不局限于数据库服务，特别是三层及多层架构的普及后，业务实现的重心已经迁移到web服务器中，为什么？因为数据库服务已经不能承载面向全球百万级甚至亿级用户请求的计算压力。唯一的解决办法就是分布式的集群方案，算力不够，服务器来凑，不买性能强劲的昂贵的服务器，转而购买巨大数量的性价比高的廉价服务器，1台不够就2台，2台不够就10台，10台不够那就百台千台。
那么业务逻辑就完全不能交给数据库么？显然不能这么绝对，数据库有数据库的优势，而且现在数据库的读写分离，分库分表等技术，也大大减轻了单台数据库服务的压力。对于一些逻辑简单而不会给数据库造成过大压力的业务查询完全可以交给数据库完成。无非是一个权衡利弊综合考虑的经验问题。
评论0
加载中...
如果是小项目，业务层写在存储过程中也无妨，如果是大型项目，劝你还是封装起来写代码里，假设大型项目的业务层写在存储过程中，抛开性能不说，后期维护起来豪不夸张的说就三个字:要你命
评论0
加载中...
关于这个问题应该分场景，不能一概而论。中小项目推荐使用存储过程解决大部分业务，代码量少，方便维护。大型项目涉及到分布式，缓存等等，考虑到数据库的开销就不建议太过依托数据库处理了，因为大并发下数据库处理复杂业务根本处理不过来。
评论0
加载中...
目前能想到的场景里 只有统计报表系统 部分报表聚合逻辑适合写在sql中 开发效率较写在中间层要高 大部分报表可以做到sql查询所见即所得。但是 要求研发有很强的集合概念 熟悉库表结构 sql语法 和 各种sql方言
其他场景 例如 各个业务线比入订单流程 等 数据库的作用还是回归存储 比较好 其他的逻辑控制等防在中间层比较好
评论0
加载中...
SQL做些基本操作就可以了，业务判断还是要在代码中实现，但在做报表的时候，按照在代码中用增删改查来操作，会存在大量的查询和更新，这是极其耗时的，应该尽可能用一条SQL去完成，同时还要注意性能优化。
评论0
加载中...0
回答0
回答0
回答0
回答10
回答0
回答0
回答2
回答0
回答0
回答
