Professional Documents
Culture Documents
Oracle PL/SQL
Development
Standard
Page 1 of 17
PL/SQL Development Standard
Contents
Page 2 of 17
PL/SQL Development Standard
Page 3 of 17
PL/SQL Development Standard
So, this is necessary that everyone follow at least some sort of guidelines so
that collaboration among team members becomes easier over the time.
This document just provides some best practice guidelines. It should not be
considered as gospel as situations might dictate slight deviations from this
guideline.
Page 4 of 17
PL/SQL Development Standard
Page 5 of 17
PL/SQL Development Standard
Naming Standard
Page 6 of 17
PL/SQL Development Standard
Design guideline
The comments can be viewed via common “desc” command in SQL Plus (or
any other client tool).
A flow chart (eg. Visio diagram or similar) must be provided for end to end
processing for which PL/SQL code needs to be developed. As a minimum, the
flow chart must show the names of input/output tables for each module.
Having a flow chart is very useful for pin pointing the exact place of failure in a
long batch job.
Page 7 of 17
PL/SQL Development Standard
Coding guideline
Comments in code
Use sufficient comments to describe what the section of code is doing. At the
beginning of a big procedure/function, clear description should be given and a
description of how the flow of program follows.
Whenever possible use explicit column names with INSERT statement. This
will help to preserve code if columns are added or deleted from table later.
Whenever possible replace for loops with set statements. The later is more
efficient than the former.
Page 8 of 17
PL/SQL Development Standard
Cursor should only be used when it is not at all possible to re-write the part of
the code using set operators.
All data must be read from and written into database tables. If some input files
come from OS files, a process should be there to upload these ASCII (or
whatever) files into database tables first.
Similarly, if output needs to be written to ASCII files (or similar), then output
data must be written to table(s) first and then a separate process should be
there to unload/extract data from output table(s) to OS file(s).
Page 9 of 17
PL/SQL Development Standard
Often a procedure writes its output to a table and after it finishes, another
procedure starts reading data from that table. If the 2nd process does not need
to wait for 1st process to finish, i.e. 2nd process can start its own processing as
soon as 1st job starts pumping its result, use of intermediate table can be
avoiding by judicial use of pipeline functions.
Cursors
Cursor should be opened in for loop to avoid explicit opening and closing of
cursor.
Example:
create or replace procedure proc_test1 IS
CURSOR cTest IS SELECT * FROM test1 ORDER BY 1;
/* contains one number column and values from 1 to 10000 */
TYPE tTest IS TABLE OF cTest%ROWTYPE INDEX BY PLS_INTEGER;
ctTest tTest;
i NUMBER := 1;
BEGIN
OPEN cTest;
LOOP
FETCH cTest
BULK COLLECT
INTO ctTest
LIMIT 1000;
FOR j IN 1..ctTest.COUNT
LOOP
-- do processing
--dbms_output.put_line(ctTest(j).abc);
NULL;
END LOOP;
Page 10 of 17
PL/SQL Development Standard
Here the limit clause specifies in single fetch to database, how many records
will be collected. It table test1 has 10,000 records; then the output line will be
printed from 1 to 10 for limit 1000.
Write this
FORALL indx IN deptlist.FIRST..deptlist.LAST
UPDATE employee SET salary = 10 WHERE employee_id= deptlist(indx);
Page 11 of 17
PL/SQL Development Standard
Security
Database security should be designed from the beginning and not as an
afterthought!
All users should have their own log in id. Everyone in same group (eg.
developers, system testers etc.) should be assigned to specific roles. The
resource for each role should be allocated to avoid resource contention (i.e.
space issue, load on servers etc).
PL/SQL code can be wrapped to hide coding logic in case when application is
deployed to 3rd party server with intellectual property right remaining with
developers only.
Page 12 of 17
PL/SQL Development Standard
Error Handling
A generic error handling routine and table are recommended. A log table
instead of log file is recommended as writing to operating system files breaks
portability of application between platforms (like Windows and Unix).
Example of how you can call this code in your procedure is shown below.
Page 13 of 17
PL/SQL Development Standard
PNAME VARCHAR2(100);
PDESC VARCHAR2(100);
BEGIN
PNAME := 'SELECT RECORD';
PDESC := 'STARTED SELECTING RECORD FROM TABLE';
INSERT_ERROR_LOG(SQLCODE, SQLERRM, PNAME, PDESC);
EXCEPTION
WHEN OTHERS THEN
DBMS_OUTPUT.PUT_LINE(SQLERRM);
INSERT_ERROR_LOG(SQLCODE, SQLERRM, PNAME, PDESC);
END;
For large procedures (which has over 400 lines and takes over 15 minutes to
run as base line), it is advisable that developers take care that execution of
each stage of modules are reported in log table.
When a program fails, just reporting the error message in the log is not often
sufficient to debug the program efficiently.
A clue must be provided which provides some pointer to exactly where the
program failed.
That is why it is advisable that developers log start and end of each module of
execution so that it becomes easier to pin point exact place of failure.
There are some cases when error handling is not advisable! If a code is
executed manually directly on database (i.e. not from a front end application)
and there is no other error handling than simple WHEN OTHERS, then it
becomes very difficult to debug if the procedure/function fails. If error handling
is missing, Oracle just points out exactly on which line code failed – so makes
it faster to debug the code.
Page 14 of 17
PL/SQL Development Standard
Any suitable name may be used as statement identifier provided that name is
not already existing in the PLAN_TABLE.
Page 15 of 17
PL/SQL Development Standard
So, it is recommended that at early testing phase (ideally during unit testing),
the code be peer reviewed so that all omissions to standard are pointed out
and corrected.
Page 16 of 17
PL/SQL Development Standard
Document control
Version Date Author Comment
1.0 Oct 2009 S Basak
Page 17 of 17