Overview of Packages and Subprograms |
Oracle offers the capability to store programs in the database. This functionality enables commonly required code to be written and tested once and then accessed by any application that requires the code. Database-resident program units also ensure that the same processing is applied to the data when the code is invoked, making the development of applications easier and providing consistency between developers.
You can write database-resident programs in PL/SQL and manage source types such as PL/SQL packages, procedures, functions, and triggers. The actions include creating, compiling, creating synonyms for, granting privileges on, and showing dependencies for these source types.
Subprograms and Packages: Usage Information describes the main types of PL/SQL program units: packages, package bodies, and subprograms.
You can use PL/SQL to develop packages and stored (standalone) subprograms. Both packages and stored subprograms are saved and stored in the database and can be used as building blocks for applications.
This topic includes the following topics:
|
See Also: PL/SQL User's Guide and Reference to learn about PL/SQL code and program units. |
Subprograms, which are either functions or procedures, can be compiled and stored in an Oracle database, ready to be executed. Once compiled, it is a schema object known as a stored procedure or stored function, which can be referenced by any number of applications connected to that database.
The SQL CREATE PROCEDURE statement is used to create stored procedures that are stored in the database. The SQL CREATE FUNCTION statement is used to create stored functions that are stored in an Oracle database.
|
See Also:
|
Subprograms are stored in a compact compiled form. When called, they are loaded and processed immediately. Subprograms take advantage of shared memory, so that only one copy of a subprogram is loaded into memory for execution by multiple users.
|
See Also: Oracle Database Express Edition 2 Day DBA Guide for information on managing memory with Oracle Database |
Stored subprograms defined within a package are known as packaged subprograms. Those defined independently are called stored or standalone subprograms. Subprograms nested inside other subprograms or within a PL/SQL block are known as local subprograms, which cannot be referenced by other applications and exist only inside the enclosing block.
Stored subprograms are the key to modular, reusable PL/SQL code. Wherever you might use a JAR file in Java, a module in Perl, a shared library in C++, or a DLL in Visual Basic, you should use PL/SQL stored procedures, stored functions, and packages.
You can call stored subprograms from a database trigger, another stored subprogram, or interactively from SQL*Plus. You can also configure a web server so that the HTML for a web page is generated by a stored subprogram, making it simple to provide a web interface for data entry and report generation.
A package is a schema object that groups logically related PL/SQL types, variables, and subprograms. Packages usually have two parts, a specification (spec) and a body; sometimes the body is unnecessary. The specification is the interface to the package. It declares the types, variables, constants, exceptions, cursors, and subprograms that can be referenced from outside the package. The body defines the queries for the cursors and the code for the subprograms.
You can think of the spec as an interface and of the body as a black box. You can debug, enhance, or replace a package body without changing the package spec.
The SQL CREATE PACKAGE statement is used to create package specification (specs). The CREATE PACKAGE BODY statement is used to define the package body.
The spec holds public declarations, which are visible to stored procedures and other code outside the package. You must declare subprograms at the end of the spec after all other items (except pragmas that name a specific function; such pragmas must follow the function spec).
The body holds implementation details and private declarations, which are hidden from code outside the package. Following the declarative part of the package body is the optional initialization part, which holds statements that initialize package variables and do any other one-time setup steps.