Re: PL/SQL .vs. Pro*C

We are comparing apples and oranges, if we are comparing a host language (Pro*C, Pro*Ada etc.) to PL/SQL.

PL/SQL is a database language, and it will be faster if the work you are performing is with the database. If you want to validate a date in your C program, and you decide to use the to_date function to do that - then PL/SQL will be slower - but the question is why are you using PL/SQL for such an operation?

A complete application cannot be developed in PL/SQL because you cannot develop a front-end in PL/SQL. You need a 4GL (Forms, PowerBuilder etc) or a 3GL (C, Pascal etc). Pro*C is needed if you choose to use 3GL for the complete application (screens, reports, interface etc.) Should that 3GL application use Embedded SQL or Embedded PL/SQL - that depends on what you are doing. If you want to simply retrieve 100 records for your screen, a simple SQL fetch into an array will probably be faster. If you want to do a complex operation involving several cursors, then encapsulate the logic in a PL/SQL procedure and call that from Pro*C. Any host environment (4GL or 3GL) MUST accomodate for PL/SQL interface and that is for a variety of reasons:

-	Performance
-	Encapsulation of database tasks 
-	Modularity
-	Availability to multiple technologies, ie. the same PL/SQL 
	procedure may be called from Forms, Pro*C, Pro*Ada, 
	SQR, Reports
-	etc.

MatthewLF_at_pobox.com wrote in article <6gtbfe$1jc$1_at_nnrp1.dejanews.com>...
> Am wondering if anyone out there has had experience using both PL/SQL and
> Pro*C. Specifically, I'd like someone to explain to me why I would use
Pro*C
> to do something which could be done in PL/SQL. I have just been on a
project
> which used Pro*C with embedded SQL to do all Oracle operations. I did
not
> write any of the code myself, but I have written scads of PL/SQL. I
found
> myself looking at pages of Pro*C and thinking to myself that I could do
it
> much easier in PL/SQL since it was 95% data manipulation. The only
argument I
> have heard so far is that Pro*C is faster than stored
procedures/packages. If
> this is the only argument I'd like some feedback on just how much faster
it is
> (all of our routines on this project are too small to do any benchmarking
> with). It seems to me that unless it is several times faster, the
benefit of
> execution time does not outway the nightmare of maintenance time.
>
> Thanks for any input.
>
> Matt.
> MatthewLF_at_pobox.com
>
> -----== Posted via Deja News, The Leader in Internet Discussion ==-----
> http://www.dejanews.com/ Now offering spam-free web-based newsreading
>
Received on Mon Apr 13 1998 - 11:20:08 CDT