[讨论]为了效率,应该把基础运算交给数据库还是程序?
问题的起源在这里: 点击进入原帖

在原帖的7楼, 一位朋友提到了"把麻烦留给程序比留给数据库效率高。"

谈谈我的看法:
这个问题, 我是想当然的继承了一些前辈流传的认知, 我认为是把一些数据库支持的基础操作应该留给数据库自己去处理, 个人认为数据库可能会结合运算本身和数据库查询做一些优化处理, 但是, 这仅仅是个人的猜测, 没有实际数据的支持.

请各位前辈, 牛人(勿论大牛小牛牛x)关于这个问题给一个有数据支持的结论.

------解决方案--------------------
简单的运算由数据库处理
复杂的运算就交给程序去做
------解决方案--------------------
既然是讨论，那就谈谈自己的意见。
我觉得不是麻烦留给谁效率更高的问题。留给程序有留给程序的好处，留给数据库有留给数据库的好处。具体留给谁应该是看需求，并结合服务器的性能以及其他一些因素来综合考虑，不同的场景，同样的程序和数据库，计算处理留给谁，其性能也完全不一样。
我曾经做过某省级电信单位处理短信收发的平台。简单描述下需求：
1.短信分两种：实时短信、非实时短信。实时短信，就是类似源手机发给目标手机，短信网关即时收到了源手机短信之后，储存、处理，转发到目标手机上去，再接收目标手机的回执等相关信息，储存。非实时短信，就是每个月的话费、水电费之类的在固定时间段需要发送到目标手机的那些短信。
2.数据量：实时短信的不说了，非实时短信的，每个月1号大概在100万条以上，其他天日均50万条左右。
再写我们当时的机器以及处理：
开发的机器，1G内存2CPU。数据库Oracle10g所在服务器也一样，程序跟数据库是两台机器。。当时是把短信的拆分以及组装<因为短信网关的原因，一条短信只能接收70个汉字，所以有些长短信需要拆成两条甚至几条短短信，组装的意思就是有的短信发送的目标一致，可以把两条甚至最多100条打包成一个package发给短信网关>放在数据库里面来处理。然后，开发的时候那个慢啊，每秒最多只能插入200条左右，这与客户要求的每秒插入1000条差不多差了一个数量级，后来我们就优化啊，这整那整的把能从数据库移出来的处理都移出来了，终于优化到了400条左右。还是差很多。后来我们没办法了，就拿到客户的测试机去，测试机还不是正式环境，它只是4G内存4CPU，妈的程序放上去一跑，每秒能插入4000条，我考，这就是服务器性能的差别了，后来我们又把从数据库里面移出来的处理又给放回去了。每秒仍然超过2000条。。
最终的正式环境，8G内存16CPU，靠，最后我们基本上把所有的复杂处理都丢给数据库了，但它还是跑的那个欢啊，最终吃不消的根本不是数据库也不是我们的程序，而是短信网关吃不消了，我们每秒可以发10000多条过去，所有的网络流量全给占了，最后限制了我们每秒最多只能发1000条。。。。

罗嗦了这么多，只想说，一定要区分程序处理还是数据库处理哪个效率高，我是没有答案的。在现在硬件条件越来越好的情况下，放在哪里都没多大关系了。。。。。。有些有钱的单位，开口就是“性能不好？还要加多少台机器，做个方案上来！”，我考。。。。。。我们还在这里讨论程序好还是数据库好，人家扔点钱下去就已经摆平了～～～～


------解决方案--------------------
"把麻烦留给程序比留给数据库效率高。"

我不太赞同这句话
------解决方案--------------------
我个人认为是哪个空闲就扔给谁，充分的调用资源才是王道
------解决方案--------------------
个人感觉没啥区别
根据项目要求来看。
------解决方案--------------------
应该平衡服务器与客户端的压力，充分利用资源。我之前的一个项目因为数据量大，计算复杂，所以我在一小部分客户端上进行计算，每个客户端运算一部分数据，运算完后传回服务器，其他客户端直接从服务器读取运算结果。

我认为服务器要做的是尽快提取数据（以最简单，最快速的方式提取数据），并发给更多的客户端（并发访问），这些要求满足之后再来分担复杂的运算任务。
------解决方案--------------------
个人感觉不能只凭感觉而选择是给程序还是给数据库，一切还得看实际的情况。在不同的运行环境和不同的应用可能是完全不同的结果，不可一概而论。
------解决方案--------------------
能够交给数据库的最好交给数据库，比如事务处理。代码只负责组装输入数据（含数据提取、必要的验证、重组，如上面哥们说的短信拆分）和输出（含用户界面、显示、工作流），中间过程程序不要介入。
优点：1）怎么说数据库都比自己开发的程序更安全、更高效、更稳定（相信没有几个敢不服这个的）
2）有利于系统模块开发、移植和升级。代码和数据库各自关注自己的重点，数据库提供接口给代码即可。耦合度很小


------解决方案--------------------
先保证数据库存取速度最大的情况下，再交给数据库一些额外的任务。
------解决方案--------------------
既然数据库对处理数据比较擅长，那就应该把那些涉及大量的数据交给数据库，而所用数据比较少的应该给程序。仅仅是个人的一点看法啊
------解决方案--------------------
数据库作为数据管理系统，对基础数据整理应该比较有优势；
复杂的计算还是应用程序做比较好，
------解决方案--------------------
关键 要把 服务器的压力 分开来承担！
如果数据库和项目不是在同一台机器上的话，那就多给点东西给数据库去作把
------解决方案--------------------
为什么没人说传输的overhead?
如果程式需要从数据库提取大量数据才能完成计算的话
考虑将运算放在数据库会有优势

而如果处理简单又强行把它放到数据库
那明显会令数据库效能下降
而扩充数据库负载能力明显比扩充程式难得多

当然...最切合实际环境的才是好方案
小系统花时间做极限优化不如升级机器
大系统一点点效能提升都可以省不少钱

------解决方案--------------------
简单运算，比如a+b，round、trun等　用数据库实现，因为从执行计划上看用不用的消耗是相同的。
分组计算，比如count，应该用数据库实现，如果是oracle，会根据索引返回总记录数，而无须操作实际表，速度非常快；而sum，也应该用数据库，毕竟返回一套记录和多条记录是有差距的