Re: VS: Re: [SPAM] oracle-l Digest V8 #84

  • From: Michael Fontana <michael.fontana@xxxxxxxxxxx>
  • To: Timo Raitalaakso <rafu@xxxxxx>
  • Date: Thu, 24 Mar 2011 17:13:06 -0500 (CDT)

----- Original Message -----
From: Timo Raitalaakso <rafu@xxxxxx>
To: michael fontana <michael.fontana@xxxxxxxxxxx>, oracle-l@xxxxxxxxxxxxx
Sent: Thu, 24 Mar 2011 15:09:30 -0500 (CDT)
Subject: VS: Re: [SPAM]  oracle-l Digest V8 #84

Timo wrote:
Hibernate is not a reason for a problematic query. It is just another SQL 

Michael wrote:
I respectfully disagree.  While Hibernate IS a SQL generator, it is a 
particularly horrible one.  

Actually I agree. Have you found a good SQL query generator? It is not 
Hibernates fault that the query is what it is. Someone has written the code 
using a framework. The coder should know how to use Hibernate. It is possible 
to use it wisely. That is hard and needs knowledge. It takes too long time to 
learn using Hibernate wisely. 

Writing a complex query using criteria api = digging your own grave. Use SQL 
with a complex case. Hibernate makes a simple case easily. But it also might 
make a easy case inefficiently when used foolishly. It is so easy to use 
Hibernate inefficiently by accident.

So happy. Our latest project without Hibernate. It took only seven years to 
unlearn a bad habbit.

When I arrived on this project, the goal was to take an existing application, 
written primarily with Hibernate against a DB2 database, and migrate to Oracle. 
 Almost immediately, problems ensued, and each development "fix" only generated 
more, the least of which was poorly optimized SQL.  

While it's right to say that any product which generates SQL can do so in an 
optimized fashion, or be tuned after the fact, at what point is that an 
efficient use of precious resources?  

I researched this topic quite extensively, and found out that Hibernate has 
major fans in the development community because it takes sql coding knowledge 
out of the mix for most developers.  They also mistakenly believe that it 
eliminates costly and scarce DBA skills as well, yet someone needs to maintain 
what is a logical representation of the data model in the Hibernate 
environment, including changes;  They will need to reconcile the fact that this 
tool fails to keep up with the latest features, functionality and syntax of all 
the RDBMS vendors, and readily points out that these issues need to be handled 
manually.  The scariest part of this is that Hibernate will even generate DDL 
if you let it!

While I can mention some fairly decent SQL generation products, and others on 
this list have already done so, none of them would be recommended for large 
enterprise systems where drastic consequences can ensue when untested query 
plans hit large sets of data potentially hundreds of thousands of times, 
perhaps even in a single transaction.  

In doing my research, AskTom had an interesting thread on this very subject, 
and an interesting conclusion was reached:


Other related posts: