来源|公众号|叫香蕉的程序员|作者| cxdh
原文地址： 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来编写所有的逻辑，很多企业都想用数据库
这些逻辑应该写在哪里的讨论从未停止过，不仅发生在后端和数据库端，而且也经常发生在前后端。 现在只讨论后端和数据库方面的矛盾。
从这五个方面分别比较两种模式的异同：
出现场景
开发效率
缺陷故障诊断
架构升级
系统维护
三、出现场景1、SQL
我们大部分的历史代码都是在存储过程中实现的啊。 如果有新的需求，不去其上的话，很难和原来的逻辑兼容呢。
前面的人是这样写的。 我是来看大家这样写的。
2、Java
是新的应用啊。 我想怎么写？
监视和埋葬很容易写。 故障诊断很方便。
前面的人是这样写的。 我是来看大家这样写的。
四.开发效率1、SQL
这样写真快啊。 而且，写Java代码很辛苦呢。 写SQL后，如果我自己在数据库开发环境中跑结果正确，我会直接丢到代码中提交。 多么爽快啊！
老实说，这个样子确实会提高开发效率。 因为不用写那么多库聚合操作，一切都用SQL就可以了。 另一方面，这确实使Java代码看起来像鸡。 似乎只是从web层到数据层的数据管道。 所有if else可以写在SQL中的东西都写在SQL中。
但是，当新的需求到来或者需求发生变化的时候，我必须经常重写SQL。 如果变更不多的话，可能必须变更为原来的SQL，但是我又不敢变更，所以复印必须重新写。 更改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 ，中对于分库分表和应用拆分来说是一件非常难受的事情，真的难受。