On May 23, 3:21 am, Frank van Bortel <frank.van.bor..._at_gmail.com>
wrote:
> -----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>
so i take it that you are not really a fan of "middleware" written in
some other language that provides an interface that applications can
use (via CORBA or something) and talks to the database via SQL.
Received on Wed May 23 2007 - 09:14:25 CDT
