软件项目本身会有很多分类。在IT传统项目/内部系统中，往往仍有很多项目采用复杂逻辑写入sql或存储过程的做法。当然并不代表这个做法是最佳的。
还是先抛出结论。
单单从技术角度讲，是绝不应该将复杂逻辑写入sql的。如果题主对原因不敢兴趣，看到这里就可以了。下面我会简单解释下这么做的一些原因。
首先，先说说传统IT服务类项目。类似，电信，政企，银行，XXX管理系统，XXX运维系统。
这类项目往往是国企，事业单位，外包，公司内部，系统表现就是低频高熵(即：系统的并发和用户量不高，但是每次请求返回的数据量较大)。这类项目由于用户少，系统压力并不是特别大。采用复杂的sql语句去直接把压力扔给数据库，并不会有太大的问题。
另一方面，由于外包项目和内部系统，往往存在开发周期短，资金供给不太足，所以一般会采用这种较快的开发方式。复杂的数据处理，逻辑过滤，都会一股脑的扔给数据库去处理。但是，单单从技术角度看，从系统性能和单机的用户容量上看，这么做，显然不是特别科学。完全可以用更少的机器，去支持更多的用户。
其次，常见的互联网技术架构。类似在线电商，O2O，生鲜等。
互联网公司由于大多系统是高频低熵(即系统的并发和用户量巨大，但是每个用户返回的数据只和自己订单相关，数据量少)。而高并发的系统瓶颈，往往在网络IO和磁盘IO上。数据库的吞吐，很快会成为系统性能的瓶颈。因此，对于高并发大流量的系统，我们要尽可能的减少数据库压力，使单次查询的时间尽可能短。缓存和分库分表等一系列操作，都是为了尽可能的减少数据库的读写压力。
这里贴上一张常见的互联网公司数据切片的操作。
最后，作为技术人员，我推荐采用互联网技术架构的思路去解决项目中的数据库问题。以最少的成本，性能最好的优化代码，才能提高相应的技术能力。如果所有问题丢sql，性能不够加机器，同样能解决问题，但显然不是一个技术人员应有的追求。
当然至于代码的可读性，可维护性等其他的，这些也算是原因之一，但并非是主要原因。
对互联网公司技术架构设计有兴趣，欢迎查看我之前的回答，里面有相关的公司架构设计发展的历程。有问题随时讨论，谢谢。
评论0
加载中...
首先复杂的逻辑写进sql，会大大减少业务逻辑和业务代码的编写，但1.可读性不强，2.不易扩展，3.不好维护，建议视情况而定。另外sql编写不宜关联太多表影响性能容易出现慢查询导致系统崩溃。
评论0
加载中...
复杂的逻辑怎么写进sql中？
sql是对数据库管理系统操作数据表的语言命令，复杂的逻辑是对不同sql语句的调用，难道能写进去？
再者编程的一大特点就是高内聚，低耦合，单一原则，一个逻辑一段代码执行一个功能，你非要耦合到一块，后期怎么维护，怎么升级？
评论0
加载中...
是否应该将复杂的逻辑写进sql中，取决于以下要素：
1、是不是要面对多个应用的调用？例如：A应用和B应用都需要调用的，直接写到SQL中是可以的，可以避免多应用之间重复编码，更新同步不及时等；如果只在一个应用或模块中调用，不建议写进SQL中，毕竟SQL语言的灵活性不如市面多数开发语言；
2、是不是需要考虑业务逻辑的安全性？在某些对业务逻辑有保密性要求的应用，直接写到SQL中是可以的，有助于减少应用开发过程中的业务逻辑安全风险；
3、逻辑变化程度？对于经常需要变更的逻辑，写到SQL中是不明智的。SQL编写效率，测试效率都不如市面多数开发语言。
4、项目开发团队的能力偏向？如果项目中，团队主要成员倾向于将复杂的逻辑写进sql中并且其他（她）成员没有能力完成业务逻辑时，就应该将复杂的逻辑写进sql中，加快项目推进与可靠性。
评论0
加载中...
用数据库处理业务逻辑是非常好的做法，但是把业务逻辑写进SQL文就不值得推荐了。
数据库可以直接对应各种业务模型，代码简单明了，省去了很多内存操作和多余的流程控制逻辑。实际开发中应该最大限度地把这些优势发挥出来。
评论0
加载中...0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答
