逻辑写在SQL中还是写在后台程序代码中

       最近转去了做互联网开发，看到了最大的不同就是后台代码算法比较多，模块服务化，很多逻辑都写在了后台代码中，比如各种计算甚至连诸如分组排序这种SQL最擅长的功能。

       到底逻辑是应该写在后台程序中还是SQL中？这个话题其实没少讨论过，我这里仅想把一些看法总结下。如果这个问题交给数据库专家去回答，那么十有八九的答案是写在SQL中，理由如下。

• 性能尽在掌控中，集群，共享存储，表分区，索引，in memory table, 安全，成熟，稳定，让我更有自信。
• 能适应业务的快速变化，不需要打包编译，大部分时候改下视图或者存储过程就ok.
• 往往用后台代码写的复杂逻辑只需要一条SQL就搞定（前提是保证性能），这样能减少网络开销，只传输需要的数据，减少网络调用次数，同时也减少了应用服务器的压力。
• 后台程序太自由，标准不统一，维护成本更昂贵。

    如果是一个Java专家或者架构师可能会这样说，将逻辑尽量写在后台代码中，理由如下：

• 后台服务的扩展比数据库扩展容易，理论上能无限水平扩展。
• 对数据库的性能依赖小，可移植性好，阿里曾经在去IEO的浪场中由O移植到Mysql。
• 对于大部分的应用性能瓶颈都在数据库的方面，表设计以及SQL应该尽量简单,这样各种ORM框架能发挥最大的用处。
• 关系数据库有性能扩展瓶颈，对于大型互联网应应该该鼓励去关系化。

       以上是我总结的各门派的观点，任何一方大师都没有说错，但是拿到网上讨论的时候没有加上任何上下文会以偏概全。一个大型的系统信息输入量很大，我们需要将OLTP跟OLAP分开。对于OLTP系统，在乎的是响应时间，对于读多写少的数据我们使用本地、分布式缓存，而且有很多更新的事务操作，根据OO的职责单一原则，对于需要频繁访问或者对数据库性能把控不好的情况下，我们确实应该将SQL写的尽量不要太复杂，不要将业务写在trigger或者存储过程中。这里前提别忘了，数据库的性能瓶颈是对磁盘的IO, SQL依然能做很多方便的工作，比如分组计算，这是各种数据库最基本的功能，并不会产生太大的额外开销，而这种功能写在后台代码中需要通过网络将所有的数据传输过来再分组。对于分布式缓存，我们有很多的计算结果不一定来自于OLTP，我们可以将数据实时的复制到OLAP系统，让OLAP计算出结果了存入缓存以服务的方式提供给OLTP去调用。

      对于系统做迁移，我也谈谈我的看法，大家都一致认为由于数据库平台的差异性导致SQL的可一只性不怎么好，这个不可否认，但是如果一个系统需要迁移了，基本是旧的系统架构支撑不了日益增长的业务了，这种迁移工作本来就是一个很复杂的工程，涉到架构的变动是大概率事件，这种情况下还讨论可移植性还有多大意义？ 通常都是换架构框架的多，单纯换数据库的少。

     对于可读性，我觉得都不应该以五十步笑百步，SQL的优势在于逻辑集中，而后台的服务程序分散，还要依赖于开发人员的素质。无论哪种方式都不如文档，无论什么形式的文档，只要能将问题表述清晰都是很有帮助的。曾经做过项目交接工作，当问项目负责人某个不常用看起来简单但是很重要功能的具体实现逻辑的时候，迟迟没有回应，后来我就自己去读代码，各种服务交叉调用，各种缓存到处设置，阅读起来非常吃力。而如果强调写SQL,我曾经看过让我看一眼就望而却步的SQL, 各种case when,各种函数，达到上千行。