Oracle PL/SQL Best Practice

2.1 Overview
1.1 Scope
This document defines the standards and guidelines that will be used by developers when
submitting PL/SQL components. These guidelines will also be used by reviewers to determine
whether a component submission meets standards.

2.2 Standards
2.3 Packages and Procedures
All PL/SQL functions and procedures will be implemented as part of a package. The package names
used will be specified in the component specification.

2.4 Function/Procedure Comments

A header should appear at the start of any script, procedure, function, package body, or package
spec. Consider this template header:

-- *****************************************************************
-- Description: Describe the purpose of the object. If necessary,
-- describe the design of the object at a very high level.
--
-- Input Parameters:
--
-- Output Parameters:
--
-- Error Conditions Raised:
--
-- Author:      <your name>
--
-- Revision History
-- Date            Author       Reason for Change
-- ----------------------------------------------------------------
-- 03 JAN 2015     J.Schmoe     Created.
-- *****************************************************************

The possible parameter types are ‘In’, ‘Out’ and ‘InOut’.

2.5 PL/SQL Statements Per Line

Place only one statement (or part thereof) per line of code. Break compound statements over
multiple lines. Do not exceed a maximum line width of 80 characters (including indentation). Due to
space limitations, the lines in this book are limited to a maximum of 70 characters.

If your code has a complex equation or formula that is expressed using a single statement or
operation, consider breaking the code into several smaller statements to make the operations less
intimidating. The equation will be much easier to debug; in addition, the process of breaking the
equation into subsections will increase your awareness of any mistakes that you make.

1
2.6 Indentation
Indentation will be 0 spaces for the outermost block and 3 spaces from the indentation level of each
enclosing block.

2.7 Alignment
Comma separated lists will be ‘stacked’ and aligned as shown below:

SELECT SUM(A)

,B

,C

FROM TABLE1

WHERE B = 5

GROUP BY B

,C

2.8 Conditional Blocks

In a conditional, the ‘THEN’ keyword will be placed on the line below the ‘IF’ but aligned with it.

‘ELSEIF’ keywords will also be aligned with the ‘IF’.

Example:

IF l_total > lc_max

THEN

l_new_max := true;

ELSIF l_total = lc_max

THEN

l_new_max := false;

END IF;

2.9 Reserved Words

SQL and PL/SQL reserved words (SELECT, INSERT, PACKAGE, FUNCTION, etc) will be capitalized.

2.10 Variable Names

When declaring variables and constants, the developer should preface a meaningful identifier.
Variable names will be all lower case, with individual words separated by an underscore. The
following standard prefixes will be used:

Prefix Usage Context

p_ Function and procedure parameters

l_ Function and procedure local variables

2
g_ Package global variables

lc_ Function and procedure local constants

gc_ Package global constants

2.11 Variable Initialization

Variables will only be initialized in the ‘DECLARE’ section when that initialization doesn’t require a
function call or complex logic. When the variable must be initialized via a function call or complex
logic, it will be done in the executable section of the procedure or function.

2.12 Alignment of PL/SQL Operators

These guidelines enhance the readability of code by adding white space and clarifying complex
expressions.

Arrange series of statements containing similar operators into columns whenever it will not
cause excessive white space and you have sufficient room to do so.
 
Correct:

  vFirstName := 'Roger';
  vLastName  := 'Smith';
  vSSN       := 999999999;

Incorrect:

  vFirstName := 'Roger';
  vLastName := 'Smith';
  vSSN := 999999999;

Always use parentheses in expressions containing more than one identifier or literal. This
clarifies code for inexperienced developers who are not familiar with operator precedence
and helps eliminate the possibility that you have overlooked something in your equation.
 
Correct:

  IF (nSSN < 2.5) THEN

     <statements>
  END IF;

Incorrect:

  IF nSSN < 2.5 THEN

     <statements>
  END IF;

Align the IN and OUT keywords in columns when defining the interface for a procedure or
function.
 
Correct:

3
   PROCEDURE Days_Between (dStartDate   IN     date,
                          dEndDate     IN     date,
                          nGPA         IN OUT number,
                          nDaysBetween    OUT number)
 
  <procedure declarations and body>

Incorrect:

  PROCEDURE Days_Between (dStartDate IN date,

                          dEndDate IN date,
                          nGPA IN OUT number,
                          nDaysBetween OUT number)
 
  <procedure declarations and body>

When calling a procedure or function, align the parameters into a column. This reduces the
visual clutter around the call, making it stand out from the rest of the code.
 
Correct:

  DaysBetween (dStartDate   => dEnrolledDate,

               dEndDate     => dGraduationDate,
               nGPA         => nFinalGPA,
               nDaysBetween => nDuration);

Incorrect:

  DaysBetween (dStartDate => dEnrolledDate,

               dEndDate => dGraduationDate,
               nGPA => nFinalGPA,
               nDaysBetween => nDuration);

2.13 Function and Procedure Naming

Stored procedures and functions should be named first by the type of action the object
performs and then by the object of that action. For example, a procedure that calculates
interest on a student's remaining balance would be named Calculate_Balance_Interest.

Packages should be named in accordance with the general purpose of the procedures and
functions contained within the package. For instance, a package containing routines used to
calculate a student's GPA would be named GPA_Calculations.

All documentation pertaining to system design should follow the conventions identified in
this standard. This applies especially to pseudocode that is used to document stored PL/SQL
objects.

4
2.14 Encapsulation

DML Statements
Insert and Update statements will be encapsulated in a single package procedure or function.

This will allow all inserts and updates to use identical SQL which will decrease statement parsing.

2.15 Control Structures

Conditionals
The ‘ELSIF/ELSE’ construct will be used in preference to multiple or nested conditionals.

Example:

These statements:

IF l_count_1 = l_count_2

THEN

// handle case 1

END IF;

IF l_count_1 > l_count_2

THEN

// handle case 2

ELSE

IF l_count_2 > l_count1

THEN

// handle case 3

END IF;

END IF;

Should be written as:

IF l_count_1 = l_count_2

THEN

// handle case 1

ELSIF l_count_1 > l_count_2

THEN

// handle case 2

ELSIF l_count_2 > l_count1

5
THEN

// handle case 3

END IF;

Loop Exits
It’s considered bad practice to exit from the middle of a loop. Each loop should include only a single
exit point.

GOTO Statement
PL/SQL’s GOTO statement will not be used.

2.16 Exceptions

Raising Exceptions
PL/SQL components will not raise exceptions directly. The component will use a single procedure to
encapsulate exception raising logic. Exceptions will be used to indicate errors, not as a normal
method for branching control.

Custom Exceptions
Custom exceptions will be declared in the package specification. Custom exceptions will not hide an
underlying exception. For example, the developer should not catch a system-created exception and
then raise an application exception instead.

Exception Handling
Exception handling code will catch specific exceptions and will only use the ‘WHEN OTHERS’
construct in the outermost code. Every effort should be made to preserve the root cause of
exceptions to the client code.

2.17 Cursors

Declarations
Multi-row cursors are often useful to users outside the package and should be included in the
package specification at the designer’s discretion.

Cursor For Loop

A cursor for loop will not be used to retrieve a single row. Cursor for loops will only be used when
every row in the cursor will be processed. If the loop exits before the all rows are read from the
cursor, then the cursor will not be properly closed.

Fetching
Cursors will be fetched into cursor records, not into multiple variables.

Select For Update

Select for update will be used when one or more of the selected rows will be updated.

6
2.18 Functions

Boolean Functions
The only valid values that may be returned from Boolean functions are ‘true’ and ‘false’. NULL
should never be returned from a Boolean function. Boolean functions may raise exceptions.

OUT Parameters
Functions should not contain ‘OUT’ parameters.

2.19 SQL Queries guideline

 Remove unnecessary large-table full-table scans - Unnecessary full-table scans
cause a huge amount of unnecessary I/O and can drag-down an entire database and
it's a SQL best practice to identify unnecessary full scans and remove them by adding
indexes.
 
 Cache small-table full-table scans - Caching is a SQL best practice in cases where a
dedicated data buffer is available for caching table rows.
 
 Verify optimal index usage - This is one of the most important SQL best practices
where you examine your SQL and verify that your SQL is using the most selective.
 
 Use Materialized Views:  Materialize your aggregations and summaries for static
tables - One SQL best practice features of the Oracle SQLAccess advisor is
recommendations for new indexes and suggestions for materialized views. 
 Use subquery factoring and global temporary tables.
 Use function-based indexes
 Use subquery factoring and global temporary tables
 Avoid using NOT IN and HAVING: 
 Instead use NOT EXISTS Use MINUS instead of EXISTS
 Never nest subqueries use GTT (global temporary tables) instead
 Never use select * in SQL:  If the DBA changes the columns, the SQL will fail
 Always generate an execution plan for all production SQL
 Always test your SQL with production CBO statistics (migrated from PROD).
 Always place SQL inside PL/SQL packages.
 Freeze SQL execution plans (using optimizer stability) when performing an upgrade.
 Only analyze with dbms_stats when you want execution plans to change.
 Tune vendor SQL by swapping execution plans