Architecture
The PL/SQL run-time system and compilation is a technology, not an independent product. Consider this technology as an engine that compiles and executes the PL/SQL blocks and the subprograms. The engine can be installed in an Oracle server or in an application development tool like Oracle Forms or Oracle Reports. Therefore, PL/SQL can reside in two environments:
(i) The Oracle server
(ii)Oracle tools
These 2 environments are independent. The PL/SQL is bundled with the Oracle server but might be unavailable in several tools. In either environment, the PL/SQL engine accepts as input any valid PL/SQL block or subprogram. The Figure shows the PL/SQL engine processing an unidentified block. The engine executes procedural statements but sends SQL statements to the SQL Statement Executor in the Oracle server.
Figure: PL/SQL Engine
(i)In the Oracle Server
The Application development tools which lack a local PL/SQL engine should rely on Oracle to process the PL/SQL blocks and subprograms. Whenever it contains the PL/SQL engine, an Oracle server can process the PL/SQL blocks and subprograms as well as single the SQL statements. The Oracle server passes the blocks and subprograms to its local PL/SQL engine.
Anonymous Blocks
The Anonymous PL/SQL blocks can be embedded in an Oracle Pre-compiler or the OCI program. At run time, the program, lacking a local PL/SQL engine, send these blocks to the Oracle server, where they are compiled and executed. Similarly, interactive tools like SQL Plus and Enterprise Manager, lacking a local PL/SQL engine, should send an anonymous block to the Oracle.
Stored Subprograms
The Subprograms can be compiled individually and stored permanently in an Oracle database, and is ready to be executed. A subprogram explicitly CREATED using an Oracle tool is known as stored subprogram. Once it is compiled and stored in the data dictionary, it is a schema object that can be referenced by any number of applications connected to that database.
The Stored subprograms defined within a package are known as packaged subprograms. Those defined independently are known as stand-alone subprograms. Those Stored subprograms defined within another subprogram or within a PL/SQL block are known as local subprograms, that cannot be referenced by other applications and exist only for the convenience of the enclosing block.
The Stored subprograms offer higher productivity, memory savings, better performance, application integrity, & tighter security. For e.g., by designing the applications around a library of stored procedures and functions, you can avoid the redundant coding and increase your productivity.
You can call stored subprograms from a database trigger, another stored subprogram, an OCI application, an Oracle Precompiler application, or interactively from SQL Plus or Enterprise Manager. For e.g., you might call the stand-alone procedure create_dept from SQL Plus as shown:
SQL> CALL create_dept('FINANCE', 'NEW YORK');
Database Triggers
A database trigger is a stored subprogram related with a table. You can have Oracle that automatically fire the database trigger before or after an INSERT, DELETE, or UPDATE statement that affects the table. One of the various uses of database triggers is to audit the data modifications. For e.g., the following database trigger fires whenever the salaries in the emp table are updated:
CREATE TRIGGER audit_sal
AFTER UPDATE OF sal ON emp
FOR EACH ROW
BEGIN
INSERT INTO emp_audit VALUES ...
END;
You can use all SQL data manipulation statements and any procedural statement in the executable part of a database trigger.
(ii)In Oracle Tools
Whenever it contains the PL/SQL engine, an application development tool can process the PL/SQL blocks and subprograms. The tool that passes the blocks to its local PL/SQL engine. The engine executes all the procedural statements at the application site and sends only SQL statements to Oracle. And hence, most of the work is completed at the application site, not at the server site.
Moreover, if the block contains no SQL statements, the engine executes the whole block at the application site. This is very useful if your application can benefit from conditional and iterative control.
Often, the Oracle Forms applications use SQL statements merely to test the value of the field entries or to do simple calculations. By using the PL/SQL instead, you can avoid calls to the Oracle server. Furthermore, you can use PL/SQL functions to manipulate the field entries.