RE: Object relational features and performance

Jeremy - Our developers have received a lot of Java training, and if I understand what you are saying, we are planning to do exactly what you describe -- normalized data structures in Oracle and an abstraction layer for the Java programmers. Would you mind to send a UML diagram that describes this "EB + session facade pattern"? Are you doing the entire abstraction on the Java side, or are you calling Oracle stored procedures?

    On a more general note to everyone, does anyone know of a book that would be helpful for an Oracle DBA that is trying to master what is needed to support Java programmers or make decisions in the area of Java and Oracle?

Dennis Williams
DBA, 40%OCP
Lifetouch, Inc.
dwilliams_at_lifetouch.com

-----Original Message-----
Sent: Friday, December 20, 2002 12:25 PM To: Multiple recipients of list ORACLE-L

> From: Stephane Paquette [ mailto:stephane_paquette_at_yahoo.com
<mailto:stephane_paquette_at_yahoo.com> ]
>
>
> Is this the future ???
>
> I know one big bank where the development is object
> oriented and the database (DB2 UDB in this case) is
> used as a big flat file. The development is using
> java, j2ee, bea weblogic.
>

Here's another thought.

Take a strong look at the J2EE architecture. The concept of Entity Beans + Session Facade pattern is a strong means of maintaining the 2 important concepts of OO and relational data. For quite a while I worked to develop a strong abstraction layer to maintain normalized data in the db, but give the Java developers a true OO API. Now with Entity Beans and intelligent design elements I've got the best of both worlds.

Transactional data is most effeciently stored in most cases in normalized form. The issue is to not force OO developers to make the leap in their code. Entity Beans are not strictly OO (since you must reference them by a PK), but are close enough to meet the needs of at least 90% of the enterprise development projects, IMHO.

If the data access is minimal, I suppose the above solution would be fine. I'd hate to try to roll out an app with a significant amount of transactions with that structure, though.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: DENNIS WILLIAMS
  INET: DWILLIAMS_at_LIFETOUCH.COM

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).