Oracle 8i and 9i PL/SQL Collections and Records
A
Component of Elegant
Database
Applications
| Why use PL/SQL? |
|
| If your application is mainly OLTP, with
short, single-action DML statements issued by the client, there really isn’t
a compelling reason to use PL/SQL. Just build a nice, data-layer framework in
the language you’ve standardized on for the client side. |
|
| But if your application needs: |
|
| - to issue several SQL statements in
succession for each user or event-triggered action |
|
| - to process large amounts of data in
batches |
|
| - to avoid the latency and overhead of
transporting data over the network for processing that could be done in the
database |
|
| - to comply with some architectural
directive to keep all the business or data layer logic in PL/SQL |
|
| then PL/SQL is the ticket! |
|
| For those who have used PL/SQL as a core
component of their enterprise applications architecture, you no doubt have
run into a few frustrating limitations of PL/SQL. We’ll talk about these
limitations, how 8i and 9i new features solve every one of them, and dive
into some examples that should help solidify the concepts and give you ideas
on where you could use the new features in database and application design. |
|
| However, I didn’t want to just give you all
the answers; it doesn’t tend to stick. Getting your hands dirty, solving a
work problem by yourself; this is what develops the real PL/SQL skills and
expertise. What’s that old maxim? “If you teach a man to fish…” I didn’t know
the exact wording or author of that old proverb, so I looked it up. At first
I ran across a few that didn’t quite say what I had in mind: |
|