存储过程优势讨论

shenyinghe

支持“存储过程”的理由主要是性能更好

那么，当压力超过单机数据库的时候，“存储过程”模式有好的扩展方案吗？

除此以外，就先不提“存储过程”+app混合的维护有多么蛋疼这个问题了。

it_kevinshaw

后台异步处理就很好，为什么一定要用存储过程呢，什么东西都交给数据库去做，还要开发人员干什么，还要架构干什么

devilkin0312

shenyinghe 发表于 2012-12-25 13:46
支持“存储过程”的理由主要是性能更好

那么，当压力超过单机数据库的时候，“存储过程”模式有好的扩展 ...

嗯，优势对应自然就是劣势的问题，procedure 在编写，调试，维护以及扩展上存在一些问题，这些问题其实等同于关系数据库的分布式问题一样。

devilkin0312

it_kevinshaw 发表于 2013-1-11 19:11
后台异步处理就很好，为什么一定要用存储过程呢，什么东西都交给数据库去做，还要开发人员干什么，还要架构 ...

这个就涉及到平衡性问题，我觉得可以再起一贴讨论时候在项目中使用procedure这个问题来讨论。

wolfyuan

我经历过的情况是, 某些数据的获取要经过很绕的逻辑, 很复杂的SQL. 这个时候面向对象的RD用对象实现不了, 而直接在面向对象语言中用很复杂的SQL对他们来说很痛苦, 这个时候通常情况下都会要求数据库端通过存储过程或者函数实现.
另外我的一个感受是, 复杂SQL语句中的某一部分使用函数来解决通常情况下会使程序可读性更好, 也更方便维护, 但是性能通常不会好, 毕竟是每条记录都要执行函数.
但使用函数能够起到固化一部分执行计划的作用, 这在某些复杂SQL中是很有用的.

baiyaj

存在就是合理的，没必要说用哪个，不用哪个，这些完全根据你的需求和实际环境来做，比如一个大型系统，包括网站、后台服务程序以及其它后台程序，那么网站这块你可以用框架理论来实现和数据库的交互，而对于后台程序来说（比如c++服务程序），通过调用存储过程来实现复杂的接口逻辑，只需要关心输入输出就行了，这时使用存储过程效率最高！
我想说的是没有哪个更好，也没有什么过时不过时的说法，完全根据实际情况来，用哪个能更高效地解决问题，就用哪个，甚至可以两种都使用，千万不能被某些理论绑架，理论都是可以被推翻的

devilkin0312

baiyaj 发表于 2013-1-17 17:32
存在就是合理的，没必要说用哪个，不用哪个，这些完全根据你的需求和实际环境来做，比如一个大型系统，包括 ...

嗯，本身出发点是讨论procedure 有那些优势来着，，

digdeep126

nmlzh 发表于 2012-6-18 17:00
存储过程作为一种过时的语言，只能存在于较少的业务场景了，比如规范的数据仓库数据清洗、标准、简单的多数 ...

如果一个架构师对数据库的理解不是特别深入，那么我觉得不是一个合格的架构师。DBA听程序员的话有点搞笑，程序员倒是应该经常咨询DBA或者开发DBA。

按照TOM的说法，依赖于数据库的大型企业应用，如果团队没有对数据库了解有一定深度队员，那么该应用很难取得成功。或者说当压力上来之后，肯定会出现问题。银行好像从安全的角度考虑，都是使用的存储过程。在数据库之外，根本看不到SQL语句。也避免了SQL注入。

个人的一点小见解，请指教。

grantguan

存储过程还有一个优点，后台维护起来方便，
DBA 可以浏览存储过程确定需要优化，添加新的索引，
如果完全放在客户端，指望程序员去做索引，会非常悲崔。

ggg3838

存储过程如果大量数据删除，更新统计信息，是不是存储过程要重新编译