[讨论]为了效率,应该把基础运算交给数据库还是程序?
问题的起源在这里: 点击进入原帖
在原帖的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，也应该用数据库，毕竟返回一套记录和多条记录是有差距的
查询条件的运算，比如where to_number(a)=5，最好别用，因为有可能这个字段上有索引，但是用上函数之后，索引失效，结果是灾难，除非用函数索引
还有一些逻辑判断的，比如主键重复，这种完全可以在数据库中控制，就不用程序去判断了，只需要去获取数据库的错误异常
再说一下题外话
有两种极端论者：
1 纯java：杜绝用存储过程，为了实现通用性和跨平台性
2 纯数据库：所有数据库交互都应该用数据库来实现，为了实现速度、性能和解决问题
以上两者都是极端表现，只需要恰当使用即可（其实这是废话）：
如果一个报表涉及到一堆表，对于每个表的查询、关联相当繁琐，那么就可以考虑用数据库（存储过程）去做；相反如果一条简单的sql就能实现的查询，还用存储过程，那真是画蛇添足
涉及到多个子查询，而且获取的数据量很大，比如从百万以上的表中获取数据，那就应该用存储过程。毕竟特定数据库都可以进行优化设置，而且减少了io的消耗，这种情况明显是用存储过程；如果用java的话，那简直就是灾难
[解决办法]
分两种情况：
如果是B/S结构，由于网站一般采用三层结构，网页也不能承载太多记录的显示，基本上数据库就起到存储数据和简单计算的作用，取出的数据在程序里实现面向对象，复杂的业务逻辑，这对三层结构的网站开发来说是比较适用的，所以对B/S结构，计算偏重于程序实现。
如果是C/S结构，而且涉及到的数据非常大，比如有很多表，每个表的数据达到百万级别，常常需要从这些数据中招到符合复杂条件的记录，这时大部分的计算只能放到数据库了。为什么？用ado.net也能做么，把需要的数据取到缓存，然后在缓存里搜索符合条件的数据？基本上很难有这样的缓存来承载这些数据。所以对于数据量非常大的C/S程序，计算偏重于数据库实现。
[解决办法]
简单数据处理逻辑可以放到数据库去实现, 而复杂的业务计算和处理,建议在程序里面处理.
[解决办法]
看情况的~~
看你公司人员呀，资源呀，等综合考虑吧！
如果这个算法数据库和程序都能搞。
取效率、用数据库（一般用存储过程或触发器，费服务器资源，维护麻烦，移植性差）
取安全、易用用程序(要与数据库交互，大数据量效率低)
[解决办法]
看需求来定，过多的东西拿给数据库处理也不是什么好办法，都那个程序处理也不什么好办法，我觉得还是看需求平均分配，利用好计算机的性能，才能发挥出数据库和程序的能力。
[解决办法]
呵呵 程序是最主要的，不要什么都给数据库处理
[解决办法]
计算(运算)由程序处理,数据的存储交给数据库.
[解决办法]
[解决办法]
数据库＝程序+数据源
[解决办法]
能不交给数据库 就尽量不要让数据库参与不必要的逻辑运算。
应用的扩展要比数据库的扩展容易的多。应用集群上万台都很容易，但是数据库要集群成本可以很高的。
一天 1亿pv 如果把这个pv成生的 数据库操作，就简单的select 可能都会把数据库搞垮了。
但是应用可以 用1000台分摊一下很容易。
[解决办法]
要综合利用资源，但也要考虑后天系统的可维护性，有些运算如果一味的依靠程序的话，显然数据库（仓库或挖掘）的功效没有发挥；同时程序过大会导致实时访问比较差，试想大家喜欢一点就出结果还是等5、6秒甚至老半天再出结果的好；当然这里又马上出现和数据库数据量的关系，如果程序健壮，那么时长显然和数据量及数据开发有关；这么说来，似乎是没什么定则的，但是从整体上来说，我们应当考虑后期维护，不要让一方很轻一方很重，而且强耦合，这样会很麻烦的！Java开发的那些框架是程序开发的很好的例子，何尝不借鉴一下呢？
[解决办法]
楼主之前的实验不是已经说明问题了么. 数据库服务器算是200条,客户端程序算是400条,
我倒是觉得楼主最后得出的结论才叫不合理了, 虽说很多客户做项目确实很大方,那要是真碰上个不大方的你又能咋办?
既然楼主的题目就是问效率,那就应该回到程序效率上来,因为程序效率是开发者能控制的,而用户实际的硬件平台则不是开发者能控制的.
[解决办法]
3l学习了~
我在做一个类似 数据监视的程序。
就是根据提供的地址或者某人的ID，放爬虫爬网页数据，然后 分析网页内容。然后项目组大家在讨论的时候就 有不同意见 这个处理该放哪儿好。
[解决办法]
恩，不错，阅读过。
还是基础的就数据库自己处理，复杂的程序处理吧。
[解决办法]
也是菜鸟说说自己的一点想法。
我是刚工作一年的新手，记得去年刚毕业那会公司的一个项目中有一个小需求
就是在到处的Excel报表中怎家一列用来显示产品的分类路径。而数据库表中
的分类是树形的表结构是这样：
type_id,type_name,parent_id
当时我的同事对java不是特熟悉对数据库很在行就写了个sql server的存储过程.
结果区区几千条数据花了2分钟，这样的效率实在很离谱，当然有可能是我的同事
写的程序有问题。后来另一个同事把所有分类数据一次性查询出来，用java做递归
然后用poi导出excel，结果几秒钟就ok了。
后来经理规定复杂操作一律不允许用数据库去完成。后来又发生了几次因为数据库
导入数据而没有导入存储过程的事件，现在连存储过程都不让用了.
[解决办法]
数据只用一次且逻辑不复杂的交给数据库
数据需要重复使用，或者逻辑比较复杂，交给程序
[解决办法]
数据库吧，减少网络传输次数
[解决办法]
数据库是用来存数据的，不是用来处理计算的
设计数据库有一个标准就是只用来保存数据，运算相关的操作尽量放到程序中去
这样会明显提高性能
[解决办法]
还是程序做吧，不到万不得已不要过多依赖数据库
[解决办法]
[解决办法]
我没看完所有人的，但我觉得，能交给数据库的就交给数据库，很多时候，我们操作都要去先取出数据再进行操作，还不如将他丢给数据库，省下了数据交换的时间。特别现在很多网站程序和数据库不再一个服务器上就更适用了。
[解决办法]
一家之言：
小量计算，基本上是等价的，唯一要注意的是，不要因为某些表达式或者函数的使用，导致索引或者数据库缓存不可用，得不偿失。如果没有影响，放在哪边，效率似乎不会有本质的区别——不可能C/java的自增或者比较需要N条汇编指令，而数据库需要2N,3N条汇编指令
大量运算，肯定放在程序侧，因为到目前为止，我还没有听说利用数据库进行多线程计算、网格计算、CUDA计算的例子。而我上面提到的几个名词，显然对效率有极大改善
[解决办法]
[color=#FF0000][/color]
[解决办法]