| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Wrapping all tables with packages and scalability
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"
on 5/2/04 9:32 AM, Ryan at ryan.gaffuri_at_cox.net 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_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Sun May 02 2004 - 11:37:57 CDT
 |
 |