Oracle Page 4 - Generic Architecture for Caching Table Data: Supercharge Your PL/SQL Applications |
With these three procedures in place, the logic for retrieving department data becomes very simple really:
§ 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) 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 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 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 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.
blog comments powered by Disqus |