一些简单的计算，应该放再资料库还是逻辑代码中？

简单的例子，select sqrt(100);还是select 100;拿到数据然后在逻辑代码中开方？

It depends.

可以从时间复杂度的角度来判断这个问题, 如果一个问题是On, 就走资料库, O1就走客户端.

举例来说, 一个页面展示10条数据, 对于这个页面来说, 排序是On的, 因为排序和页面展示的数据条数无关, 需要遍历所有数据; 但是对于页面上货币的标化就是O1的(永远只有10次运算), 这个就可以方面页面上来做.

在实际情况, 根据API封装的粒度和业务不同, 还是需要具体情况具体分析.

作为一名DBA，我认为资料库只用来做简单的操作，复杂的运算放在代码逻辑层面，有助于资料库的更好的

业务层计算。

资料库应只做增删改查的操作。任何情况下都建议这么做。1. 资料库做逻辑会有无穷无尽的坑。要知道你认为简单的代码，后面有新需求会产生各种问题。2. 性能，业务层都是内存处理，资料库会涉及大量io

3. 方便移植。如果有需要改底层资料库，比如mysql改postagesql，那么sql越简单，移植工作量更少。

4. 优化。如果代码是性能瓶颈，在业务层，低级语言改造，分散式等等各种花样随便玩。资料库的话就…

前面几个回答都是教科书式的，但是在现实生活中往往更新/改变业务层比更改资料库要频繁地多。而且业务层的deployment 往往更麻烦。有一个强大伺服器上的好资料库（Oracle) 完全可以把逻辑放在资料库里，维护更简单。

资料库资源宝贵，当然应该放在业务方处理

虽然说具体情况具体分析，但一般地来说：如无特别特殊的原因，能放到业务节点处理的逻辑都应该放到业务节点处理，而不应该把计算任务交给资料库服务节点来处理。原因其实很简单：一般如果设计上没有太大问题，业务节点的横向扩展都是比较容易的，而资料库服务一般都是一个比较「中心化」的服务，它的性能是宝贵的，而且横向扩展难度大，维护难度也更高。