Oracle
  Home arrow Oracle arrow Page 4 - Generic Architecture for Caching Table...
Dev Shed Forums 
Administration  
AJAX  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Forums Sitemap 
IBM® developerWorks 
Sun Developer Network 
Dedicated Servers 
E-Commerce Hosting 
Linux Web Hosting 
Managed Hosting 
Small Business Hosting 
Actuate Whitepapers 
VeriSign Whitepapers 
VPS Hosting 
Weekly Newsletter

 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
ORACLE

Generic Architecture for Caching Table Data: Supercharge Your PL/SQL Applications
By: Mark Vilrokx
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 5 stars5 stars5 stars5 stars5 stars / 10
    2005-10-11

    Table of Contents:
  • Generic Architecture for Caching Table Data: Supercharge Your PL/SQL Applications
  • Why a Caching Architecture?
  • An Example
  • Retrieving department data
  • Conclusion

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
    IBM developerWorks
     
    ADVERTISEMENT

    Generate data entry and reporting .NET Web apps in minutes, straight from your database. Read our FREE whitepaper “Build Web 2.0 Applications Without Hand-Coding” Download now!

    Generic Architecture for Caching Table Data: Supercharge Your PL/SQL Applications - Retrieving department data


    (Page 4 of 5 )

    With these three procedures in place, the logic for retrieving department data becomes very simple really:

     

    • Read the department data from the cache

    §        If it was not found in the cache, query it from the database

    §        If it was found in the database, write it to the cache.

       FUNCTION dept_data (p_dept_id IN dept.deptno%TYPE)
          RETURN department_tp
       AS
          l_dept_data   department_tp;
       BEGIN
          l_dept_data := read_from_cache (p_dept_id);
          IF (l_dept_data.NAME IS NULL)
          THEN
             l_dept_data := read_from_db (p_dept_id);
             IF (l_dept_data.NAME IS NOT NULL)
             THEN
                write_to_cache (p_dept_id, l_dept_data);
             END IF;
          END IF;
          RETURN l_dept_data;
       END dept_data;

    Now wrap all these functions and procedures in a package body, call it dept_cache and expose all the types and the dept_data function (by putting them in the package header).  There is no need to expose any of the other procedures.

    Now, if you want to get department data, you just call the dept_data function.

       DECLARE
          l_dept_data   dept_cache.department_tp;
       BEGIN
          l_dept_data := dept_cache.dept_data ('10');
       END;

    Notice how the whole caching logic is completely transparent for the users of your package.  Nobody knows that it is using a cache (and neither should they have to know).

    When you get your collection of employee data you can now simply loop over the data and invoke dept_cache.dept_data passing in the DEPTNO of the record you are currently processing, e.g.:

       DECLARE
          l_dept_data   dept_cache.department_tp;
       BEGIN
          FOR emp_rec IN (SELECT *
                            FROM emp)
         LOOP
             l_dept_data := dept_cache.dept_data (emp_rec.deptno);
             DBMS_OUTPUT.put_line (   emp_rec.ename
                                   || ' works in the '
                                   || INITCAP (l_dept_data.NAME)
                                   || ' department which is located
    in '
                                   || INITCAP (l_dept_data.LOCATION)
                                  );
          ENDLOOP;
       END;

    In order to find out how much of a performance gain this caching is giving us I conducted a little test.  We will query 200.000 records using the read_from_db function (note that you will have to make the read_from_db function temporarily public to be able to run the test).  Then we will do the same test using the dept_data function.  Here is what I get on my Test DB:

       Timings when reading 200000 records from the DB = 2132 ms
       Timings when reading 200000 records, using the cache = 238 ms

    These results will obviously vary, depending on your DB (version, setup…) and the volume of data in your department table, but typically you will see a huge increase in speed when caching your data.

    More Oracle Articles
    More By Mark Vilrokx


       · Hi,This is my first article in this series on how to cache Table Data to speed...
       · Is there a performance improvement over joining the two tables?
       · well u have done a remarkable job... tats great!!!!
     

       

    ORACLE ARTICLES

    - Tuning PL/SQL Code
    - Debugging PL/SQL Code
    - Testing PL/SQL Code
    - Working With PL/SQL Code
    - Conditional Compilation for Oracle Database ...
    - Compile-Time Warnings for Oracle DB 10g
    - Compiling PL/SQL Code for an Oracle Database
    - Troubleshooting PL/SQL Code
    - Managing PL/SQL Code
    - Data Manipulation and More for HTML DB Appli...
    - Oracle Database Fundamentals
    - Adding Processes to HTML DB Applications
    - Adding Computations, Processes, and Validati...
    - Sub-templates and More with Oracle HTML DB
    - Focusing on Templates in Oracle HTML DB





    © 2003-2008 by Developer Shed. All rights reserved. DS Cluster 5 hosted by Hostway