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.
[EMAIL PROTECTED]
-----Original Message-----
Sent: Friday, December 20, 2002 12:25 PM
To: Multiple recipients of list ORACLE-L
> From: Stephane Paquette [ mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> ]
>
>
> 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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
