Re: Wrapping all tables with packages and scalability

From: Nuno Souto <dbvision_at_optusnet.com.au>
Date: Mon, 3 May 2004 20:10:58 +1000
Message-ID: <011201c430f7$80bf1bc0$9b00a8c0@dcs001>

Original Message ----- From: "Ryan" <ryan.gaffuri_at_cox.net>
> I'm familiar with abstraction and Object Oriented design. This is
> essentially what you are talking about. I like it, I am just concerned
about
> scalability. If REF Cursor opening and closing has overhead..., then there
> is a concern at the very high end. I talked to some guys building an

Akshally, strictly speaking this is not OO design... It's simply abstracting
and wrapping the table itself and its basic operations with a procedural ("method")
wrapper. OO design is a bit more than just that! Hence the difficulty of relational-OO mapping.

Scalable? Let's put it this way: I don't know about traditional environments
but with J2EE it's probably the fastest and most efficient way you can interface
to the Java app layer. I've used it extensively in the last 3.5 years and it
has not yet produced any "surprises". There is a lot of meta-data traffic that
takes place in a conventional JDBC access that this technique avoids. Until such
time as some J2EE idiot decides to "complexify" it...

Interestingly with Forms 9 and 10 you can also specify a set of procedures or packages as the "base table" for a block. I've never tried it, but I'm sure it would also produce very good results.

Note that this technique does not replace conventional overhead of parsing. If you have to parse, it's still an overhead regardless of the interface. What it does is provide a more efficient interface to the Java world with JDBC. However, you MUST use the entire range of interface options: if you give your procedures the same number of parameters as there are columns in the table, then you're hardly gaining anything. You MUST use object types as the procedure interface parameters, where each object type is a row of the
table (or a part thereof).

Cheers
Nuno Souto
in sunny Sydney, Australia
dbvision_at_optusnet.com.au

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
-----------------------------------------------------------------

Received on Mon May 03 2004 - 05:11:58 CDT