Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd
Upload
321 views

Best Practices in PL/SQL: Karthikeyan M

This document discusses best practices for writing PL/SQL code. It recommends taking time for modular design with small, reusable code blocks. Specific best practices include using packages and functions to avoid repeating SQL, following naming conventions, avoiding hard coding, handling exceptions with common packages, using BULK COLLECT for queries, and using FORALL for DML operations to reduce context switching overhead. The document also provides resources for further learning PL/SQL best practices.

Uploaded by

ranusofi
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
321 views

Best Practices in PL/SQL: Karthikeyan M

This document discusses best practices for writing PL/SQL code. It recommends taking time for modular design with small, reusable code blocks. Specific best practices include using packages and functions to avoid repeating SQL, following naming conventions, avoiding hard coding, handling exceptions with common packages, using BULK COLLECT for queries, and using FORALL for DML operations to reduce context switching overhead. The document also provides resources for further learning PL/SQL best practices.

Uploaded by

ranusofi
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 15

Best Practices in PL/SQL

Karthikeyan M http://karthikeyanmect.blogspot.com

Why best practices?


Many ways of writing a code Code


Will give solution (some how) Time taken and resource consumed ? Use optimal resource Provides quicker solution

Best code

Modularized Design

Bad design

Spend more time in design Good design Less time in coding


Dump your logic in a single procedure Having lots of selects inserts updates and deletes.etc Break your logic into small blocks Grouping related logic as a single block or program
.

Modularize

Modularize will

reduce complexity make your tasks manageable make your resulting code maintainable For each major functionality With repeated DML as procedure With repeated select as functions
.

Use Packages

Naming convention

Follow a standard throughout your code


Easy to understand Easy for maintain and change Local variable l_var_name Procedure parameter p_var_name Global variable g_var_name
.

Follow the standard throughout Example your code and application


Avoid hard coding


CREATE CREATE OR REPLACE OR REPLACE PROCEDURE PROCEDURE GEN_SWIP GEN_SWIP ( an_document_number ( an_document_number IN IN number, an_serv_item_id asap.serv_req_si.document_number%TYPE IN number, , an_serv_item_id IN IN varchar(20)) an_srsi_ip_addr_seq TYPE, As asap.serv_req_si.serv_item_id% an_srsi_ip_addr_seq IN asap.srsi_ip_addr.srsi_ip_addr_seq begin %TYPE,)

as select d_no into an_document_number from task; begin null; end; end;

What happens if the d_no column changed to varchar2 type ?

Avoid SQL !

SQL is equivalent to hard-coding


Drag the performance down Difficult to maintain Selects inside functions DMLs inside procedures And call these inside your business logic

We will see an example Encapsulate your SQL for this later.


Repeated SQL as functions

This is quintessential for performance

Avoid repeating the SQL in different places Hard parsing will be avoided So spend more time in design Identify at the time of designing rather than coding

Exception handling

A common package for


Error handling Error logging Log as more a data as possible (debugging) Date of occurrence Error number , name Program name and program dataetc
.

Normally

Use BULK COLLECT for Queries

BULK COLLECT performs bulk bind of results from SQL select statement

Returns each selected expression in a table of scalars

CREATE OR REPLACE FUNCTION get_a_mess_o_emps (deptno_in IN dept.depno%TYPE) RETURN emplist_t IS emplist emplist_t := emplist_t(); TYPE numTab IS TABLE OF NUMBER; TYPE charTab IS TABLE OF VARCHAR2(12); TYPE dateTab IS TABLE OF DATE; enos numTab; names charTab; hdates dateTab; BEGIN SELECT empno, ename, hiredate BULK COLLECT INTO enos, names, hdates FROM emp WHERE deptno = deptno_in; emplist.EXTEND(enos.COUNT); FOR i IN enos.FIRST..enos.LAST LOOP emplist(i) := emp_t(enos(i), names(i), hiredates(i)); END LOOP; RETURN emplist; END;

Use the FORALL Statement

Instead of the individual FOR operations, you can do this:


PROCEDURE update_employee (p_name customer.name %TYPE) IS BEGIN FORALL cust_dt IN (select cust_name ,cust_id,cust_age from customer where cust_name= p_name )Loop Begin --bussiness logic End; END;

Used to reduce the context switching between SQL and PL/SQL engine
.

Conventional Bind
Oracle server
PL/SQL Runtime Engine
PL/SQL block

SQL Engine

FOR aDept IN deptlist.FIRST.. deptlist.LAST LOOP DELETE emp WHERE deptno = deptlist(aDept); END LOOP;

Procedural statement executor

SQL statement executor

Performance penalty for many context switches

Enter the Bulk Bind


Oracle server
PL/SQL Runtime Engine
PL/SQL block

SQL Engine

FORALL aDept IN deptlist.FIRST.. deptlist.LAST DELETE emp WHERE deptno = deptlist(aDept);

Procedural statement executor

SQL statement executor

Much less overhead for context switching

Points to remember

Take more time in designing Follow coding standard Avoid hard coding Avoid writing more SQL Write tiny chunk of code Dont repeat anything

Books/ Materials

Beginning Oracle Programming Sean Dillon, Christopher Beck , Thomas Kyte http://asktom.oracle.com http://www.toadworld.com/sf Code Complete by Steve McConnell

You might also like