| 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: JAVA Developer
I'll take a stab?
Normalize the data model. The classes can be designed in such that many a time it "flattens" the normalization of the underlying database tables. From the Java perspective it is still a single call to the database, with the result set in the required denormalized format. (Still pulling for data modeling should be done separately).
Hibernate is open source, toplink is oracles metadata layer. Changes to the database then will change the metadata, and the classes won't break. Havn't used either.
Joel Patterson
Database Administrator
joel.patterson_at_crowley.com
x72546
904 727-2546
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of
Joel.Patterson_at_crowley.com
Sent: Monday, January 08, 2007 2:57 PM
To: Andrew.Kerber_at_umb.com; oracledba.williams_at_gmail.com
Cc: oracle-l_at_freelists.org
Subject: RE: JAVA Developer
Yes, my first impression is how you develop java classes before knowing what the schema looks like, but I'm the neophyte for these purposes.
I got one response as follows: Any elaborations? Someone touch on hibernate, (and toplink) again or me.
"2 basic areas of potential conflict are how the object domain model is managed relative to physical database design, and the other is result set persistence relative to transaction concurrency.
Many java architects/developers believe that the object model should translate directly to the physical DB model. If you as the DBA allow that, your database manageability, including performance, is doomed. When you perform physical design, you'll be breaking some of their object classes, which can potentiall cause a ton of angst. In order to gain decent performance, you'll have to stick to your design guns, and if the JAVA person doesn't understand how the handoff works between object modeling and database modeling, there may be a lot of arguing.
Persistence is another hot button. If they believe in using a third party persistence engine, such as a Hibernate, this can lend itself to a lot of ambiguity between what the overall database transaction mix is doing on disk and what the result set that the persistence engine is managing for the long-running transaction that may want to execute updates/deletes based on what it sees. Content management can become problematic if the applications is not coded properly, and these can quickly become YOUR problem if you're not diligent during development."
Joel Patterson
Database Administrator
joel.patterson_at_crowley.com
x72546
904 727-2546
From: Kerber, Andrew [mailto:Andrew.Kerber_at_umb.com]
Sent: Monday, January 08, 2007 2:19 PM
To: oracledba.williams_at_gmail.com; Patterson, Joel
Cc: oracle-l_at_freelists.org
Subject: RE: JAVA Developer
I would love to hear the answer that you expect to hear for that, since the answer I would give is the Java classes would be derived from the data model.
Andrew W. Kerber
Oracle DBA
UMB
"If at first you dont succeed, dont take up skydiving"
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Dennis Williams
Sent: Monday, January 08, 2007 1:12 PM
To: Joel.Patterson_at_crowley.com
Cc: oracle-l_at_freelists.org
Subject: Re: JAVA Developer
Joel,
My question would be "Do you feel data modeling should be done separately, or should the data model be derived from the Java classes?"
Dennis Williams
-- http://www.freelists.org/webpage/oracle-lReceived on Mon Jan 08 2007 - 14:21:20 CST
 |
 |