Re: Do you use PL/SQL

From: Frank van Bortel <frank.van.bortel_at_gmail.com>
Date: Wed, 23 May 2007 09:21:56 +0200
Message-ID: <f30q2l$a1k$1@news1.zwoll1.ov.home.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Doug Davis wrote:

> On May 20, 5:08 am, Frank van Bortel <frank.van.bor..._at_gmail.com>
> wrote:

>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>
>>
>>
>> Doug Davis wrote:
>>
>>> I will be teaching aPL/SQLclass, and I wanted to get some opinions.
>>> I read aboutPL/SQL, but wanted somepracticaladvice from people who
>>> have used it.
>>> 1. Why usePL/SQLinstead of just sending SQL queries from a program
>>> written in a procedural language on the client side (Java, Visual
>>> Basic, C++, anything.)
>>> 2. What are some examples of "real-world" things that you have done
>>> withPL/SQL(or have heard some one do withPL/SQL?)
>>> thanks.
>> When asking these questions, I seriously begin to question
>> the authority to teach classes.
>>
>> These are exactly the type of questions *you* should be
>> able to answer, as an instructor!

> 
> thanks for your opinion.
> 

You're welcome.

One thing I haven't seen in this thread, is the possibility to write database independent applications.

When executed correctly, all the application does is make calls to (packaged) procedures. (packaged in brackets, as Oracle is the only RDBMS that supports that, whereas every RDBMS system with procedural extensions supports functions and procedures).

The application then does not have to "know" the ins and outs of the RDBMS, and every RDBMS programmer can implement specifics in the procedures, using the possibilities of the RDBMS to the full extent of the product.
Obviously, such an approach can only be done with whatever language the RDBMS offers natively. For Oracle, that would be either PL/SQL, or Java. Rule of thumb here (and be careful not to promote ROT to truth!) to use Java for CPU intensive stuff, and PL/SQL for data intensive stuff.

Sadly, it's all to common that apps get "re-engineered" towards db independence after the initial release(s). It may become clear from the above, such an approach requires a hell of a lot of thinking and planning, and thus is seldom (if at all) seen, while "taking too long", "being too expensive", "being too difficult".
<sarcasm>
No - having to patch systems on a monthly basis for the life of the product (5 ~ 7 years), that's smart, inexpensive, fast. </sarcasm>
- --
Regards,
Frank van Bortel

Top-posting is one way to shut me up...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFGU+uULw8L4IAs830RAiOeAJ95eB8qXi2xaMWv/Cg5SHbfXbrQHQCfeVn2 zNTH6Y3V5gK+K8cCMBp57iw=
=ZdXx
-----END PGP SIGNATURE----- Received on Wed May 23 2007 - 02:21:56 CDT