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

biti_rainy

有一些空间或者时间的损耗
要承认我们可以避免
但这个问题并不会让我们感觉到差异的话，就不是重要的非解决不可的问题

uje

faint,写了一堆都没了,现在只好长话段说了.个人看法:,存储过程是PL/SQL的代码编译后存在oracle中,可以通过多种方法调用,而PRO*C则是一个C的接口.可以说一般情况下是没有人会在存储过程调用c的方法的(虽然oracle提供这种调用的方法,但我还没看见谁用过),而PRO*C则可以调用存储过程.所以我的看法pro*c和存储过程是一个调用和被调用的关系,没有效率比较的问题.比如这是有以前写的一段pro*c的代码是把所有的PL/SQL代码全写在了我的PRO*C中,如下:
就是把下段代码中的        EMS_DEQUEUE(:msginfo);
部分全用PL/SQL写在PRO*C中.
...........
后来的写法
int
MsgReceiver::StartMsg()
{
EXEC SQL BEGIN DECLARE SECTION;
           VARCHAR msginfo[200];  
EXEC SQL END DECLARE SECTION;

//Because the msginfo is the output variable,so shall set the max length of the string.
msginfo.len=200;
bool loopflag=true;

EXEC SQL WHENEVER SQLERROR DO MsgError();
while(loopflag)
        {
          EXEC SQL EXECUTE
          
       BEGIN
        EMS_DEQUEUE(:msginfo);
           END;
          
          END-EXEC;

      msginfo.arr[msginfo.len]='\0';
          if(!strcmp((char*)msginfo.arr,"Stop")
                  loopflag=false;                                      
      else
        printf(msginfo);
          //MsgFunction();
        }
return 1;        
}
也就是说如过能用存储过程实现就用它来实现再通过PRO*C 调用就可以了,无论如何存储过程做同样的事情应该效率要高一些,只有那写不容易用存储过程来实现的,比如复杂的比较,或交互操作就用PRO*C,两者是个补充关系,没有比较关系.

jxc_hn

我指的比较是指同一各业务逻辑用两种方法实现的性能比较。
我认为还是有区别的。

uje

对啊,我的观点就是能用存储过程来实现就应该用存储过程来实现,尤其是大数据量处理的情况下.无论PRO*C再怎么快,它的程序只是一个ORACLE的客户端,数据的传输(从server到client的buffer)就会花费很多时间的,它的速度比起在server端直接执行而不需要网络传输的过程肯定是要慢的.

oracledanc

顶一下

kenny

pl/sql 还是能做很多事的，一般的业务都能做到，能用pl/sql 的还用pro c干吗？
同意uje 的看法！

john_zhu

除了一些很少的核心的，并发粒度很高的，难道语言的执行效率真的有怎么重要！？

jxc_hn

to uje:
我以前一直就用存储过程,对于大数据量的倒换（在库中各表之间转换）性能很好，但不代表pro*c性能比它差。
你说的情况是指window 客户端的pro*c吧？我没用过，我一直以来都是在Unix平台开发。一般来说pro*c所在
的机器就是oracle服务器，所以不存在你说的问题。
话又说回来,由于后台业务逻辑交互性差的特点，我们一般不会用存储过程和pro*c来进行大量的网络数据传输，
而是在后台操作数据，只把结果返回给调用者。

如果业务逻辑主要是计算密集型的，pro*c的优越性会大大超过存储过程，所以我的观点是：除非业务逻辑是
表之间数据大量倒换操作,才选择存储过程。

我选择pro*c的理由：
        1。 c程序的高性能有目共睹。
        2。 三层结构的要求业务逻辑从数据库中移出来。
        3。 一些特殊功能需要和操作系统交互，用C更方便。比如后台处理时间较长，可以通过往文件写日志来获知进度。

john_zhu

PLSQL与PROC应该有各自的定位，交叉的很少，我们认为相同的业务当然可以使用相同的方式但是在实际的操作中肯定有一种最合理的方式（微观：（ ^_^ ）

jxc_hn

其实我出道以来就是写存储过程。那时用notepad啊。

真羡慕现在写存储过程的，有pl/sql developer 这么好的工具。

但现在倾向于写pro*c了, 三层结构的中间层（tuxedo 的 service, J2EE 的 EJB）都用来实现业务逻辑了, 数据库的作用是只保留
数据，大势所趋啊。