来源|公众号|叫香蕉的程序员|作者|快乐海燕
原文地址： https://MP.weixin.QQ.com/s/62 FTZ oau _ thqa 50 v9iy 1tq
总之，我支持把逻辑写在Java等应用系统上！
背景：
今天，我们只讨论最常见的APP应用程序模型，其中前端实时调用后端Web服务，而服务端则通过数据库添加/删除调查进行响应。 关于离线数据分析，在线规则引擎模板的执行、流计算等不在本次讨论的范畴内。
看看一、重SQL还是重Java的开发场景演示一个例子。 要求调查各学生所在的城市名称和分数并展示在前端。 用经典的Controller、Service和DAO开发模型编写，设计数据库表如下：
（1）重SQL模式示例代码：
（2）重Java模式示例代码：
可见，使用较重的SQL模式进行开发确实很快，只需开发SQL就差不多了。 但是，如果你看到用沉重的Java模式开发，你就需要写很多代码。 那样的话，好像是SQL的胜利。
是的，PD突然说。 我把城市名称叫做“坎纳”。 分数乘以2进行展示。 握着草，这个怎么做？
（1）重SQL模式示例代码：
好的，不用了。 这个SQL已经变得复杂了，几乎看不见了。
（2）重 Java 模式示例代码：
咦，好像没什么变化呢。
这个时候，PD又来了。 我把城市名称叫做“坎纳”。 而且，城市代码不足10086的，将把分数加倍展示。 握着草，完了，之前都是SQL，这个需求该怎么办？ 要继续重叠CASE WHEN吗？
我还不知道。 突然DBA电话来了。 哥哥戴伊的SQL太慢了，现在正在拖整个库。 没有编制索引吗？
我：索引被添加了呢。 你没去吗？ 它是先解决慢SQL，还是先解决开发需求？ 分解库是不可能的。 逻辑这么死很复杂，拆库也完全跑不动啊。 请添加CPU和内存。 是DBA的大人物。
[DBA日报]慢SQL 180，已解决10。
版本又提高了
[DBA日报]低速SQL 200，已解决15。
版本又提高了
[DBA日报]低速SQL 250，已解决30。
渐渐地，开发、运营和DBA每天都厌倦了监视这些SQL。
二、上述示例的思考观察一下，在传统企业和大部分转型中的企业的Java APP应用中，令人惊讶的是，他们的开发者想使用一个SQL来创建所有逻辑，包括我自己。 非常多的公司使用数据库存储过程和数据库自定义函数。
这些逻辑应该写在哪里的讨论从未停止过，不仅发生在后端和数据库端，而且也经常发生在前后端。 现在只讨论后端和数据库方面的矛盾。
从这五个方面分别比较两种模式的异同：
出现场景
0px;">开发效率缺陷排查
架构升级
系统维护
三、出现场景1、SQL
我们绝大多数的历史代码都是用存储过程来实现的啊，如果有新需求不往上面做的话，很难兼容原来的逻辑啊啊。
前面的人呢是这样写的，我来了看大家都这样写就这样写了。
2、Java
新应用嘛，我想怎么样写就怎样写。
监控和埋点写起来简单吖，排查问题可方便了。
前面的人呢是这样写的，我来了看大家都这样写就这样写了。
四、开发效率1、SQL
这样写起来很快啊，而且写 Java 代码多难受啊，写 SQL 我自己在数据库开发环境跑一下结果正确我就直接丢到代码中提交了，多爽啊。
老实说，这样子确实会提高开发的效率，因为不用写那么多查库聚合的操作，一切都在 SQL 中搞定了。另一方面来看，这确实会让 Java 代码看起来很鸡肋，好像只是把数据从 web 层到数据层的一个管道而已，一切 if else 能写在 SQL 中的都写在 SQL 中了。
但是新需求来或者需求变更的时候，我经常要重新写SQL，如果变动不多我可能要改动到原来的 SQL，但是我又不敢改，所以只好 copy 重新写一个，改 SQL 的风险好大，一报错又要重启好难受。
2、Java
一次要写N个类，有点烦。
新需求来或者需求变更的时候，如果逻辑比较复杂，我直接抽成方法或者改成一些设计模式，维护起来效率还是可以接受的。
五、缺陷排查1、SQL
开发排查问题的时候，除了看日志，直接把SQL和参数丢到 PL/SQL 或者 其他工具里跑一下，基本就能知道数据问题出现在哪了。测试同学在进行测试的时候，如果发现有不对的东西，直接跟开发同学一样的思路，把SQL 跑一下，问题基本就定位得七七八八了。
但是呢，一旦遇到跑 SQL 无法一眼看出问题的 bug 或者 SQL 实在是太长太长了的的时候，就蒙圈了。我曾经就维护了一个几千行的存储过程，一旦发生问题，排查问题的过程巨艰难。但是呢直接用一个数据库一个功能搞定所有功能未尝不是一件很爽的事情，因为关系型数据库实在是实在是现实的悟空太稳定了，一次编写永久运行。
2、Java
看日志看监控。
根据报错的代码位置 check 一下代码逻辑。
一些入参分支肉眼 check 不出来，只能远程 debug 慢慢看数据流向。
测试的同学基本无法帮忙 check 缺陷，只能靠程序的表现来判断。
六、架构升级1、SQL
SQL 慢没关系，它稳定啊，慢就把机器垂直扩展一下好啦，加cpu，加内存，换SSD，加加加绝对可以解决事情的。
SQL 有各种索引和优化策略，说不定跑起来比我们自己写逻辑还快呢。
加加加，加内存加cpu垂直升级。也没有其他招数了，除了前置缓存，但是如果查询都很个性化SQL很复杂，前置缓存也基本没啥乱用。。。
如果你的逻辑全部写在 SQL 中，那完蛋了，你这个表基本就没法分表了，因为你的业务逻辑跟数据库的数据完整性是强耦合的，需要一切数据基本都在一个数据库中，这是一件很难受很难受的事情，不信你去问问那些所有业务逻辑全写在 SQL 中的小伙。
数据库中非常复杂的表关联会极大程度拖慢数据库处理每条 SQL 的平均时间，极大程度拖慢数据库 RT，降低了数据库的 RT ，如果逻辑都写在 SQL 中，那么只能进行垂直升级。因为一旦进行水平扩展，那么多机器的非常复杂的分布式表关联，RT 基本不是一个高并发的业务应用的能容忍的。
2、Java
如果是数据库瓶颈，加数据库机器，分库分表一下，应用层基本不用改，在DAO层进行路由一下。
如果是服务器cpu瓶颈，多加几台机器就好了。
如果还有瓶颈，增加一下查询缓存。
在应用快速发展的过程中一般都会分库分表的拆分或者自动水平扩展，这时候其实只需要数据库层面做好自己的数据迁移和同步就好了，对于业务层来说是完全无感知的。即使业务非常非常复杂，需要拆应用，其实也非常简单，只需要把对应的 DAO 层的操作拆分出去，换成 RPC 或者其他方式的调用就好了。
七、系统维护1、SQL
旧SQL完全不敢动，来一个需求加一个 SQL。
慢SQL日益增加，应对疲乏。
2、Java
SQL写完一次基本不用动，来一个需求加一个方法聚合一下数据操作即可。
应用维护比较简单，只要监控做好了，定位到问题基本都能很快解决。
逻辑越来越复杂，没有好的开发框架的话，代码维护起来也是挺要命，因为完全不知道跑哪个分支去了。但是现在已经有很多优秀的开源框架来更好地维护代码了，比如 Spring 的全家桶。
八、怎么破！旧的重 SQL 逻辑暂时不要动，新的逻辑都基于 Java 模式开发，先保证慢 SQL 不增加，旧的 SQL 稳定运行，毕竟业务稳定是第一要素。
如果业务初期需要非常非常快速开发，那么使用重 SQL 模式也是可以理解的，但是还是要抽时间重构成 Java 模式。
九、结论我支持将逻辑写在 Java 等应用系统中。其实原因在上面基本描述完了，第一就是复杂 SQL 的表关联其实跟个人的能力有非常大的关系，如果一个 SQL 写得不好，那是极慢极慢的非常容易把整个数据库拖慢的。第二就是维护这些 SQL 也是一件很难受的事情，因为你完全不知道这个 SQL 背后的数据流转是怎样的，你只能根据自己的猜测去查看 SQL 中的 bug，Java 应用好歹还能 debug 一下还有打点看看数据不是？如果逻辑写在 Java 中那么其实你的 DAO 层只需要编写一次，但是可以永久使用，基本不会在这一层浪费很多的时间（用过 ibatis 的都知道改了 SQL 需要重启应用吧？）。第三就是逻辑都写在 SQL ，中对于分库分表和应用拆分来说是一件非常难受的事情，真的难受。