Re: Wrapping all tables with packages and scalability
- From: Tim Gorman <tim@xxxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Sun, 02 May 2004 10:39:59 -0600
It's not new. I worked with some folks 12 years ago who designed "CUD"
packages in v7.0 PL/SQL. Each package was named "<table-name>_P" and
consisted of functions named CREATE_ROW, UPDATE_ROW, and DELETE_ROW. "CUD"
was derived from the acronym "CRUD", but the "R" for "Retrieve" in that
acronym was missing because Oracle didn't support REF CURSORs in PL/SQL at
the time, so "R" was implemented by a layer of database views. Pity the
poor lady who was tasked with maintaining this library, as she became known
as the "CUD Queen"... :-)
Obviously, the concept of functional abstraction dates back to the origins
of programming languages, and if you think about it, the SQL language itself
as well as low-level APIs like "dblib()", ODBC, JDBC, and OCI and progamming
languages like Fortran, LISP, and C are all implementations of the concept.
Otherwise, we'd all still be programming in assembler...
As with SQL et al, success is dependent on acceptance. A good idea doesn't
succeed on its own merits -- it must first be socialized.
Anecdotes about possible technical problems in high-end testing shouldn't
inhibit adoption of this design strategy, as long as one also considers the
potential benefits. For example, one project I worked on (8 yrs ago) used a
PL/SQL-based abstraction layer underneath a brand-new custom-built Java
application. The developers insisted that this level of abstraction was
unnecessary because of how wonderful Java and EJBs were.
As it turned out, for reasons I never cared to understand, the Java code set
harder than concrete because any change to any part of the code caused
side-effects throughout the entire application, raising an QA-testing
situation requiring wholesale regression testing for any change, no matter
how minor. It wasn't long before new business requirements forced an
enormous change to the underlying data-model, which would not have been
feasible if we had not been able to make all data-model changes completely
transparent to the concrete super-hardened Java code by modifying the layer
of abstracting packages and views without altering the interface.
"Creating tomorrow's legacy applications today, one crisis at a time"
- Gary Dodge, Oracle Corporation
on 5/2/04 9:32 AM, Ryan at ryan.gaffuri@xxxxxxx wrote:
> I met a guy about 2 months ago who used this design concept. Its basically
> object oriented abstraction in the database. Each table has a package. Each
> package has all the methods that operate on the table(all the SQL). SQL is
> returned with REF Cursors. I know Steve Fuerstein advocates this.
> He was stating that in a high transaction system with a max of about 700
> transactions/second, he was unable to get his parse/execute ratio above 75%.
> He noticed that Oracle did not always use bind variables on the dictionary
> cache elements used by these packages.
>
> Anyone else notice this? I have not tested it.
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
> put 'unsubscribe' in the subject line.
> --
> Archives are at //www.freelists.org/archives/oracle-l/
> FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
