20.8 What You Need to Know

Do you really need to remember everything in this chapter? I certainly hope not, though your database administrator probably does. In addition to satisfying healthy curiosity, my goal in presenting this material was to help allay any misgivings programmers might have about what happens under the hood. Whether or not you've ever had such concerns, there are a number of important points to remember about PL/SQL's runtime architecture.

• To avoid compilation overhead, programs you plan to use more than a few times should be put in stored programs rather than stored in files as anonymous blocks.

• In addition to their unique ability to preserve state throughout a session, PL/SQL packages offer performance benefits. You should put most of your extensive application logic into package bodies.

• If you don't want to bother learning how to query Oracle's data dictionary, you should probably be using a front-end developer's tool of some kind.

• While Oracle's automatic dependency management approach relieves a huge burden on developers, upgrading applications on a live production database should be undertaken with great care.

• Oracle's sophisticated approaches aimed at minimizing the machine resources needed to run PL/SQL occasionally need a little help from developers and DBAs—for example, by explicitly freeing unused user memory or pinning objects in memory.

• When you OPEN an explicit cursor in a PL/SQL program, be sure to CLOSE it as soon as you are through fetching.

• Native compilation of PL/SQL may not offer any performance advantages for SQL-intensive applications, but it can significantly improve the performance of compute-intensive programs.

• Calling remote packages entails some special programming considerations if you want to take advantage of anything in the package other than procedures, functions, types, and subtypes.

• If you are using Oracle's client-side tools, putting reusable client-side code into PL/SQL libraries generally makes sense.

• Use definer rights to maximize performance and to help simplify the management and control of privileges on database tables. Use invoker rights to address particular problems (for example, programs that use dynamic SQL and that create or destroy database objects).

• Faster CPUs, more memory, and better disk I/O will improve PL/SQL performance, but taking advantage of parallel computing still requires conscious design effort.

Chapter 21. Object-Oriented Aspects of pl/sql

PL/SQL has always been a language that supports traditional procedural programming styles such as structured design and functional decomposition. Using PL/SQL packages, it is also possible to take an object-based approach, applying principles such as abstraction and encapsulation to the business of manipulating relational tables. Later version of Oracle have introduced direct support for object-oriented programming (OOP), providing a rich and complex type system, complete with support for type hierarchies and "substitutability."

In the interest of summarizing this book-sized topic into a modest number of pages, this chapter presents a few choice code samples to demonstrate the most significant aspects of object programming with PL/SQL. These cover the following areas:

• Creating and using object types

• Inheritance and substitutability

• Type evolution

• Pointer (REF)-based retrieval

• Object views

Among the things you won't find in this chapter are:

• Comprehensive syntax diagrams for SQL statements dealing with object types

• Database administration topics such as importing and exporting object data

• Low-level considerations such as physical data storage on disk

I'd like to introduce the topic with a brief history.