50,531
社区成员
发帖
与我相关
我的任务
分享
...全文
请发表友善的回复…
发表回复
arui20082 2010-12-31
- 打赏
- 举报
谈下我的实际经历：我手头有个oa系统，其中有个模块是需要从数据库中检索数据，然后以列表打印出来，开始的时候这个模块的计算全都在一个存储过程中进行，客户反映慢的很，要2、3分钟才能看到结果，然后我把所有的运算都写到了一个java类中，问题就解决了，几秒钟就能打印出结果。
然后有一次我去面试，我把我的经历告诉面试官，而面试官大人却用充满怀疑的眼光看着我：怎么可能呢，存储过程的效率肯定比程序里计算要高！ 我很无语。。。
有没有明眼人能给个明确点的答复？
然后有一次我去面试，我把我的经历告诉面试官，而面试官大人却用充满怀疑的眼光看着我：怎么可能呢，存储过程的效率肯定比程序里计算要高！ 我很无语。。。
有没有明眼人能给个明确点的答复？
静石 2009-12-25
- 打赏
- 举报
这明显不是给谁的问题吗？
你要看程序和数据的处理性能到底在哪？
尽量的均分处理给他们的，不要搞得差别太大！
你要看程序和数据的处理性能到底在哪？
尽量的均分处理给他们的，不要搞得差别太大！
fan123123 2009-12-21
- 打赏
- 举报
呵呵，我的习惯是：
流程方面的交给程序
大量数据处理交给数据库
其他方面的二者结合处理
流程方面的交给程序
大量数据处理交给数据库
其他方面的二者结合处理
rabbit_009 2009-12-03
- 打赏
- 举报
总结一下：
我觉得，使用DBMS写过程保存的优点有：
1.对于一些简单的计算，譬如求和、求平均等，效率肯定比写在高级语言的程序里面高，尤其是数据量巨大的情况下更明显；
2.对于跨平台这方面没有太大影响，因为写数据库过程、方法等都是对外提供一个能够给高级语言调用的接口，而数据库的部署一般也会在服务器上，只要平台能支持该数据库，这些接口就能正常使用，受平台影响较大的只会是编程语言；
3.把计算写在DBMS还有一个好处，对于一些基本的逻辑计算需要变化的时候，可以直接在后台数据库里修改存储过程、方法即可，而写在程序里面则要等待下一个软件版本的变化才能更新，这点对于C/S架构的开发效果更明显。
不知道对不对，请各位高手指点一下～～
我觉得，使用DBMS写过程保存的优点有：
1.对于一些简单的计算，譬如求和、求平均等，效率肯定比写在高级语言的程序里面高，尤其是数据量巨大的情况下更明显；
2.对于跨平台这方面没有太大影响，因为写数据库过程、方法等都是对外提供一个能够给高级语言调用的接口，而数据库的部署一般也会在服务器上，只要平台能支持该数据库，这些接口就能正常使用，受平台影响较大的只会是编程语言；
3.把计算写在DBMS还有一个好处，对于一些基本的逻辑计算需要变化的时候，可以直接在后台数据库里修改存储过程、方法即可，而写在程序里面则要等待下一个软件版本的变化才能更新，这点对于C/S架构的开发效果更明显。
不知道对不对，请各位高手指点一下～～
无牛刀 2009-12-02
- 打赏
- 举报
公司的进销存产品
是c/s
几乎全部的运算都交给数据库
感觉这样子，给数据库压力太大了
是c/s
几乎全部的运算都交给数据库
感觉这样子，给数据库压力太大了
linfeng000d 2009-12-02
- 打赏
- 举报
简单的运算由数据库处理
复杂的运算就交给程序去做 但要优化程序的代码，效率高点
复杂的运算就交给程序去做 但要优化程序的代码，效率高点
铁匠梁 2009-12-02
- 打赏
- 举报
性能优化的路任重而道远
dongyangmoney 2009-12-02
- 打赏
- 举报
简单的运算由数据库处理
复杂的运算就交给程序去做
复杂的运算就交给程序去做
yylcslg5 2009-12-02
- 打赏
- 举报
看那个写起来简单,便捷
object0042 2009-12-02
- 打赏
- 举报
俺们老师说，越底层，数据的处理越快，所以我们能给数据库处理的就给数据库
zero0120 2009-12-02
- 打赏
- 举报
最基础的，觉得还是交给数据库好些
haysong 2009-12-02
- 打赏
- 举报
sql的极限，plsql的极限，存储过程的极限....这个是有的
goosman 2009-12-01
- 打赏
- 举报
[Quote=引用 97 楼 shine333 的回复:]
引用 94 楼 maquan 的回复:
引用 93 楼 shine333 的回复:
大量运算，肯定放在程序侧，因为到目前为止，我还没有听说利用数据库进行多线程计算、网格计算、CUDA计算的例子。而我上面提到的几个名词，显然对效率有极大改善
那，海量数据的分组统计，算不算“大量计算”，如果算的话，怎么说也是在“数据库里面做”更好一点吧？
听上去有点像抬杠，hehe，其实我想说的是，这个事情本质上是不可能用一个简单的判定标准来一刀切的。我想楼主开这个贴，应该也不是请大家投票的，而是发起相关的讨论。而各种观点，说到底，都离不开“具体问题具体分析”（我这句说了跟没说一样 ^_^），辩证法嘛
另外，关于海量分组，我只举一个反例，会什么会有lucene呢？
[/Quote]
正在尝试做一些测试, 弄了一千万的测试数据, mysql5.0, 其实做了很容易发现, 统计运算根本不适合放到程序中处理, 我这边也是做了才觉得很搞笑(代码写一半就一定能发现问题所在)......比如一千万条数据, 查出来放到程序中处理, 我只查了两个int(11)的字段, 耗内存1G, 将这些东西放入内存本来就很耗时了......而使用数据库提供的函数, 哪怕数据库处理的效率要低, 也绝对比拿出来要快....
所以, 目前得到的一个结论:
海量数据, 如果需要的是统计类数据结果, 一定要放到数据库中做, 不然, 将这些数据读到内存本身就已经累跨机器了.
引用 94 楼 maquan 的回复:
引用 93 楼 shine333 的回复:
大量运算，肯定放在程序侧，因为到目前为止，我还没有听说利用数据库进行多线程计算、网格计算、CUDA计算的例子。而我上面提到的几个名词，显然对效率有极大改善
那，海量数据的分组统计，算不算“大量计算”，如果算的话，怎么说也是在“数据库里面做”更好一点吧？
听上去有点像抬杠，hehe，其实我想说的是，这个事情本质上是不可能用一个简单的判定标准来一刀切的。我想楼主开这个贴，应该也不是请大家投票的，而是发起相关的讨论。而各种观点，说到底，都离不开“具体问题具体分析”（我这句说了跟没说一样 ^_^），辩证法嘛
另外，关于海量分组，我只举一个反例，会什么会有lucene呢？
[/Quote]
正在尝试做一些测试, 弄了一千万的测试数据, mysql5.0, 其实做了很容易发现, 统计运算根本不适合放到程序中处理, 我这边也是做了才觉得很搞笑(代码写一半就一定能发现问题所在)......比如一千万条数据, 查出来放到程序中处理, 我只查了两个int(11)的字段, 耗内存1G, 将这些东西放入内存本来就很耗时了......而使用数据库提供的函数, 哪怕数据库处理的效率要低, 也绝对比拿出来要快....
所以, 目前得到的一个结论:
海量数据, 如果需要的是统计类数据结果, 一定要放到数据库中做, 不然, 将这些数据读到内存本身就已经累跨机器了.
shine333 2009-12-01
- 打赏
- 举报
[Quote=引用 94 楼 maquan 的回复:]
引用 93 楼 shine333 的回复:
大量运算，肯定放在程序侧，因为到目前为止，我还没有听说利用数据库进行多线程计算、网格计算、CUDA计算的例子。而我上面提到的几个名词，显然对效率有极大改善
那，海量数据的分组统计，算不算“大量计算”，如果算的话，怎么说也是在“数据库里面做”更好一点吧？
听上去有点像抬杠，hehe，其实我想说的是，这个事情本质上是不可能用一个简单的判定标准来一刀切的。我想楼主开这个贴，应该也不是请大家投票的，而是发起相关的讨论。而各种观点，说到底，都离不开“具体问题具体分析”（我这句说了跟没说一样 ^_^），辩证法嘛
[/Quote]
另外，关于海量分组，我只举一个反例，会什么会有lucene呢？
引用 93 楼 shine333 的回复:
大量运算，肯定放在程序侧，因为到目前为止，我还没有听说利用数据库进行多线程计算、网格计算、CUDA计算的例子。而我上面提到的几个名词，显然对效率有极大改善
那，海量数据的分组统计，算不算“大量计算”，如果算的话，怎么说也是在“数据库里面做”更好一点吧？
听上去有点像抬杠，hehe，其实我想说的是，这个事情本质上是不可能用一个简单的判定标准来一刀切的。我想楼主开这个贴，应该也不是请大家投票的，而是发起相关的讨论。而各种观点，说到底，都离不开“具体问题具体分析”（我这句说了跟没说一样 ^_^），辩证法嘛
[/Quote]
另外，关于海量分组，我只举一个反例，会什么会有lucene呢？
shine333 2009-12-01
- 打赏
- 举报
[Quote=引用 94 楼 maquan 的回复:]
引用 93 楼 shine333 的回复:
大量运算，肯定放在程序侧，因为到目前为止，我还没有听说利用数据库进行多线程计算、网格计算、CUDA计算的例子。而我上面提到的几个名词，显然对效率有极大改善
那，海量数据的分组统计，算不算“大量计算”，如果算的话，怎么说也是在“数据库里面做”更好一点吧？
听上去有点像抬杠，hehe，其实我想说的是，这个事情本质上是不可能用一个简单的判定标准来一刀切的。我想楼主开这个贴，应该也不是请大家投票的，而是发起相关的讨论。而各种观点，说到底，都离不开“具体问题具体分析”（我这句说了跟没说一样 ^_^），辩证法嘛
[/Quote]
我同意具体问题具体分析。我的回复主要针对lz后面的4个问题，仅仅是针对“通常情况下”而言。
你说的这个例子，不知道您说的“海量的定义”，在我看来正好相反，绝对不可能用仅仅用数据库。
另外，我倾向于用程序解决问题，还是基于以下考量：目前的开发工具，针对程序的debug工具，特别是profile已经非常完善了，而这方面，数据库“相对”较差（不是说没有，个人感觉，功能上还差了一个档次），万一出了bug或者需要改善效率，程序肯定比数据库方便。同时，完成同样的程序，会写java/.net的肯定比会写plsql的多，而且，万一下一个项目不用oracle，而是改了db2/sqlserver/mysql，会写plsql都不一定有用
引用 93 楼 shine333 的回复:
大量运算，肯定放在程序侧，因为到目前为止，我还没有听说利用数据库进行多线程计算、网格计算、CUDA计算的例子。而我上面提到的几个名词，显然对效率有极大改善
那，海量数据的分组统计，算不算“大量计算”，如果算的话，怎么说也是在“数据库里面做”更好一点吧？
听上去有点像抬杠，hehe，其实我想说的是，这个事情本质上是不可能用一个简单的判定标准来一刀切的。我想楼主开这个贴，应该也不是请大家投票的，而是发起相关的讨论。而各种观点，说到底，都离不开“具体问题具体分析”（我这句说了跟没说一样 ^_^），辩证法嘛
[/Quote]
我同意具体问题具体分析。我的回复主要针对lz后面的4个问题，仅仅是针对“通常情况下”而言。
你说的这个例子，不知道您说的“海量的定义”，在我看来正好相反，绝对不可能用仅仅用数据库。
另外，我倾向于用程序解决问题，还是基于以下考量：目前的开发工具，针对程序的debug工具，特别是profile已经非常完善了，而这方面，数据库“相对”较差（不是说没有，个人感觉，功能上还差了一个档次），万一出了bug或者需要改善效率，程序肯定比数据库方便。同时，完成同样的程序，会写java/.net的肯定比会写plsql的多，而且，万一下一个项目不用oracle，而是改了db2/sqlserver/mysql，会写plsql都不一定有用
maquan 2009-12-01
- 打赏
- 举报
[Quote=引用 93 楼 shine333 的回复:]
大量运算，肯定放在程序侧，因为到目前为止，我还没有听说利用数据库进行多线程计算、网格计算、CUDA计算的例子。而我上面提到的几个名词，显然对效率有极大改善
[/Quote]
那，海量数据的分组统计，算不算“大量计算”，如果算的话，怎么说也是在“数据库里面做”更好一点吧？
听上去有点像抬杠，hehe，其实我想说的是，这个事情本质上是不可能用一个简单的判定标准来一刀切的。我想楼主开这个贴，应该也不是请大家投票的，而是发起相关的讨论。而各种观点，说到底，都离不开“具体问题具体分析”（我这句说了跟没说一样 ^_^），辩证法嘛
大量运算，肯定放在程序侧，因为到目前为止，我还没有听说利用数据库进行多线程计算、网格计算、CUDA计算的例子。而我上面提到的几个名词，显然对效率有极大改善
[/Quote]
那，海量数据的分组统计，算不算“大量计算”，如果算的话，怎么说也是在“数据库里面做”更好一点吧？
听上去有点像抬杠，hehe，其实我想说的是，这个事情本质上是不可能用一个简单的判定标准来一刀切的。我想楼主开这个贴，应该也不是请大家投票的，而是发起相关的讨论。而各种观点，说到底，都离不开“具体问题具体分析”（我这句说了跟没说一样 ^_^），辩证法嘛
shine333 2009-12-01
- 打赏
- 举报
一家之言：
小量计算，基本上是等价的，唯一要注意的是，不要因为某些表达式或者函数的使用，导致索引或者数据库缓存不可用，得不偿失。如果没有影响，放在哪边，效率似乎不会有本质的区别——不可能C/java的自增或者比较需要N条汇编指令，而数据库需要2N,3N条汇编指令
大量运算，肯定放在程序侧，因为到目前为止，我还没有听说利用数据库进行多线程计算、网格计算、CUDA计算的例子。而我上面提到的几个名词，显然对效率有极大改善
小量计算，基本上是等价的，唯一要注意的是，不要因为某些表达式或者函数的使用，导致索引或者数据库缓存不可用，得不偿失。如果没有影响，放在哪边，效率似乎不会有本质的区别——不可能C/java的自增或者比较需要N条汇编指令，而数据库需要2N,3N条汇编指令
大量运算，肯定放在程序侧，因为到目前为止，我还没有听说利用数据库进行多线程计算、网格计算、CUDA计算的例子。而我上面提到的几个名词，显然对效率有极大改善
yanyoujian 2009-12-01
- 打赏
- 举报
我没看完所有人的，但我觉得，能交给数据库的就交给数据库，很多时候，我们操作都要去先取出数据再进行操作，还不如将他丢给数据库，省下了数据交换的时间。特别现在很多网站程序和数据库不再一个服务器上就更适用了。
haitao 2009-12-01
- 打赏
- 举报
先要知道各自的长短
数据库的长处在于大数据量的列间运算
过程语言的长处在跨记录的运算，但是，如果记录多，仅仅从数据库取记录到程序，就会慢死了
数据库的硬件扩展代价高
应用服务器的硬件扩展方便
数据库的长处在于大数据量的列间运算
过程语言的长处在跨记录的运算，但是，如果记录多，仅仅从数据库取记录到程序，就会慢死了
数据库的硬件扩展代价高
应用服务器的硬件扩展方便
maquan 2009-12-01
- 打赏
- 举报
[Quote=引用 83 楼 lgg201 的回复:]
还没有解决的问题:
不考虑其他任何情况, 只比较下面情况下, 程序处理快还是数据库处理快, 具体问题包括数据库系统函数, 数据库用户自定义函数, 存储过程:
1. 大量数据复杂运算, 谁快?
2. 大量数据简单运算, 谁快?
3. 小量数据复杂运算, 谁快?
4. 小量数据简单运算, 谁快?
[/Quote]
我感觉，“数据库系统函数”跟“用户自定义函数”在性能上应该是差不多的，即使后者“可能”会有一些额外开销，也不会有太大影响。至于“存储过程”，我没研究过它的运行机制，总觉得它像是一种“解释执行”的东西，“效率”不会是它的强项。
还没有解决的问题:
不考虑其他任何情况, 只比较下面情况下, 程序处理快还是数据库处理快, 具体问题包括数据库系统函数, 数据库用户自定义函数, 存储过程:
1. 大量数据复杂运算, 谁快?
2. 大量数据简单运算, 谁快?
3. 小量数据复杂运算, 谁快?
4. 小量数据简单运算, 谁快?
[/Quote]
我感觉，“数据库系统函数”跟“用户自定义函数”在性能上应该是差不多的，即使后者“可能”会有一些额外开销，也不会有太大影响。至于“存储过程”，我没研究过它的运行机制，总觉得它像是一种“解释执行”的东西，“效率”不会是它的强项。
加载更多回复（74）
