请比较一下pro*c和存储过程的效率。

xiaotiao

这么多人发表意见？我也说两句了：）
个人感觉pro*c和存储过程从功能上讲是完全一样的
在大部分系统中，服务器端程序使用Pro*c的确快一些
但是从软件工程的角度上说，我还是喜欢存储过程的
因为把业务逻辑以存储过程＋触发器的方式还是比较合适的
只是为了一点速度上的提高并不值得

另外，我感觉pro*c只是为了考虑对以前的兼容才继续存在的
并没有什么存在的必要性。更通常情况下我用OCI/JDBC：）

zhrmghg

proc的效率比存储过程高很多，实际使用的结论。出人意料，但很真实。

xiaotiao

呵呵，zhrmghg兄弟所说的也许在一些平台上有可能
但我相信在大部分实现的情况下
pro*c和OCI等价

当然，你要是比较pro*c和oci做全表扫描然后fetch所有结果
当然是pro*c快了
但这种可能并不很多

longbow

pro*c 和 oci的速度是差不多的。

lander

我记得曾经看过这样一句话：
在Oracle中，首先应该考虑能否用SQL实现，如不能实现则应考虑PL/SQL，如PL/SQL不能实现才考虑PRO*C。

为什么不尽量利用Oracle提供的机制而非要比较存储过程和PRO*C之间的效率呢？
该用存储过程的时候就应该使用存储过程，该用PRO*C的时候就应该使用PRO*C。

galebird

PL/SQL <> store procedure
proc 中也可以用PL/SQL 效率是一样的
楼上所言“无论PRO*C再怎么快,它的程序只是一个ORACLE的客户端,“不敢苟同。
在处理PL/SQL 上两者原理一致。
但在其他逻辑处理上proc显然快一些。

galebird

抱歉楼上的忘了刷新了。

我记的在某本oracle手册上
对比了oci pl/sql proc。
印象中pl/sql 和proc 在处理sql 原理一至。oci的调用过程更简单一些。因此oci应该更快一些。

galebird

仔细看了一下原来我在反对UJE的意见。
“无论PRO*C再怎么快,它的程序只是一个ORACLE的客户端“是一个错误概念。
同时请教formeast
"使用存储过程能较少地占用shared pool空间，减少了语句编译、存储方面的性能损耗" 出处？
sp 存储与系统表空间。而proc中的pl/sql并不在数据库中存储。
sp编译后的结果在数据库中，脚本也在，但proc是预编译的所以在这一点是一致的。
在运行中处理pl/sql的方法也是一致的。

fromeast

我的原意：
使用存储过程能较少地占用shared pool空间，并减少了SQL编译、内存管理方面的性能损耗。

理由：
无论pro*c还是存储过程，其实都是在执行一些SQL，只不过执行方式和组织方式不同：
1.pro*c的SQL是分别传递、执行的，每个SQL占用shared pool空间中的一个条目。存储过程是作为一个整体保存在shared pool中的，一个存储过程只占一个条目。所以存储过程能较少地占用内存shared pool空间。
2.pro*c的SQL都有可能重新编译。而存储过程只编译一次。

jxc_hn

最初由 fromeast 发布
[B]我的原意：
使用存储过程能较少地占用shared pool空间，并减少了SQL编译、内存管理方面的性能损耗。

理由：
无论pro*c还是存储过程，其实都是在执行一些SQL，只不过执行方式和组织方式不同：
1.pro*c的SQL是分别传递、执行的，每个SQL占用shared pool空间中的一个条目。存储过程是作为一个整体保存在shared pool中的，一个存储过程只占一个条目。所以存储过程能较少地占用内存shared pool空间。
2.pro*c的SQL都有可能重新编译。而存储过程只编译一次。 [/B]

不知道这些描述的出处？请指明。
我认为：
1。存储过程的代码是整个存储在shared pool中，比起pro*c中的单条sql占用的空间肯定大的多。
2。存储过程确实一次编译后就驻留内存，pro*c的sql和任何sql没有区别，只有被客户端发出执行，都会被oracle分析，其执行计划也会保存在shared pool,下次有同样的语句调用时，直接执行分析了的代码。原理和存储过程没有区别。只是不清楚在shared pool中的sql、存储过程是否也和data buffer 中的数据一样用LRU管理。