• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Do we over-use hibernate?

 
Ranch Hand
Posts: 798
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just about speed and performance, (exclude object abstraction that hibernate provide), hibernate is a good option ?

If we put all of logic to database using package, stored procedure and trigger, we just call it in the java function, then wrap it to an object.

This pure JDBC design, compared to hibernate, is a good option ? or on what situation it is better solution?

Do we over-use hibernate?
 
Ranch Hand
Posts: 518
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Just about speed and performance, (exclude object abstraction that hibernate provide), hibernate is a good option ?



Yes, Hibernate performs very, very well.


If we put all of logic to database using package, stored procedure and trigger, we just call it in the java function, then wrap it to an object.



Besides a small potential performance boost, why would you want to do that? Business logic in stored procedures is difficult to maintain, ties you too closely to a single RDBMS and limits reuse of the logic.

This pure JDBC design, compared to hibernate, is a good option ? or on what situation it is better solution?



In general, no, it's not a better solution than using Hibernate and putting your business logic in a properly designed set of classes.

Do we over-use hibernate?



No, I'd say ORM tools are under-utilized.

Hibernate isn't the best tool for all problems. For example, Hibernate isn't the best way to bulk load 100 million rows. But for many other problems, it's an excellent solution.
 
Edward Chen
Ranch Hand
Posts: 798
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Besides a small potential performance boost,


how much "performance boost", do we have some test data ?

Business logic in stored procedures is difficult to maintain,/quote]
I agree with you.


ties you too closely to a single RDBMS and limits reuse of the logic


some projects, for example, company internal project, will be OK using a single RDBMS and lose some reuse.

Thank.

 
Edward Chen
Ranch Hand
Posts: 798
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry, wrong format. do it again.
=========

Besides a small potential performance boost,


how much "performance boost", do we have some test data ?

Business logic in stored procedures is difficult to maintain


I agree with you.


ties you too closely to a single RDBMS and limits reuse of the logic


some projects, for example, company internal project, will be OK using a single RDBMS and lose some reuse.
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Without spending hours posting. But underneath the hood Hibernate does a lot of preformance enhancements that can easily surpass stored procedures. Exact number and exact information I can't give you because it would take a while.

But here are some features. 1. Statements are run as prepared statements, with bind parameters, the database could already have parsed and created explain plans for these queries. Hibernate and JBossCache or EHCache with the second level cache can keep objects in memory so you don't even have to go back to the database. CRUD operations all run at time of commit, and run in JDBC Batch, instead of constant calls all over the place.

Many more

Mark
 
Scott Johnson
Ranch Hand
Posts: 518
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

how much "performance boost", do we have some test data ?



No, I don't have exact figures but I've seen it happen.

Stored procedures can perform faster than individual, prepared sql statements in some situations -- especially when you can minimize the number of round trips to the database and/or minimize the number of rows returned.

This would be easy to test for yourself. Create a test scenario (preferrably using real tables/sql from your application) and compare the performance of both options.

some projects, for example, company internal project, will be OK using a single RDBMS and lose some reuse.



Just because it's an internal application doesn't mean you won't want to migrate to a different database.

I've been involved with several projects (3 that I can think of) in the last year where we tried to move internal apps to a different platform. Some projects didn't happen and others are taking longer than necessary because of business logic embedded in stored procedures and database-specific sql.
 
Edward Chen
Ranch Hand
Posts: 798
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, Guys,
I have posted same question to Oracle forum.
http://forums.oracle.com/forums/thread.jspa?threadID=435466&tstart=0
You could see database person's view.

Thanks.
 
Scott Johnson
Ranch Hand
Posts: 518
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That's funny.

That just proves that if you ask 50 people a question, you'll get 51 different opinions. Everyone has their own perspective.

[Belch.] Time to get me some more sasparilla.
[ October 19, 2006: Message edited by: Scott Johnson ]
 
Hooplehead
Posts: 136
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Wow...interesting discussion. My two cents:

* I am a recent convert to Hibernate. In the past, my projects have been very data centric with my classes derived from the data structure. Hibernate has swapped that around for the betterment of my projects. My classes are now much more about �the problem� and less about �the technology� or �the data structure�.

* A lesson I learned (the hard way) was �use the right tool for the right job�. One should evaluate hibernate, like any other technology/tool, and see if it is appropriate for the project. Clearly, a simple �roll your own� blog site does not require hard core PL/SQL work by a specialist on a monster Oracle DBMS. A just as clearly (I hope), a mission critical volume financial transaction system would best be served by avoiding hibernate and listening to the Oracle guys.

* I like how hibernate makes a lot of those db performance decisions for you. It is probably appropriate 80% of projects. (80/20 rule.) Developer�s are, in general, really bad about predicting where performance problems will occur. Performance tuning is more science than art.

* There is some absolutely stunningly bad database work out in the wild done by programmers. If hibernate can prevent that, then it is for the best.

* The maintenance issue points the oracle guys fail to address the concept of keeping one�s biz logic in one place, and how that is good for maintainability. If a project has a little bit of logic here, a little bit of logic there, etc�well�then the application as a whole become more difficult to maintain and requires a more diverse skill set. Hibernate even isolates us, to a degree, from changes in db data structures on existing systems!

* They guys on the oracle forum have a vested interest in a database-centric world. It butters their bread. Did anyone else catch all the references to costs and hiring and retraining and such? These are enterprise DB guys talking about big projects�many of whom cannot see outside of that world. I would put forth that we Java developers on JR have a relatively more holistic view of an application and that the Oracle guys are realativily narrowly focused specialists. There are also comments on there about how they, the real smarts in the family, had to come in and save the day because some poor java smuck got in over his or her head. Maybe true�but they don�t know about all the projects that succeeded without them because nobody ever needed to come to them in the first palce. I argue that Hibernate decreases cost overall. Maybe you can tell, but I am a bit sceptical about the opinions of this bunch. I mean, how can one take the comment �Java should handle the presentation layer only.� Seriously? How very two-tier application of him!

OK, I�ll wrap my little half rant up now with a summery: Hibernate has it�s place. It can make project development more efficient. The oracle guys have their place too�but their world is a lot more specialized than they like to admit�Hibernate is after all a threat to their livelihoods.

Stu
:roll:
 
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Hibernate is good tool at least for CRUD operations. For data centric application like the one we are dealing with (millions of rows) we prefer to dump Hibernate and use JDBC calls which are way better. Also with the database abstraction layer you can gain extra benefits of stored procedures.

Also in our case we need to switch on and off databse indexes which you cannot control thru Hibernate. Our DBAs also come handy for tuning up the sqls and we know and control precisely what sqls are fired up by application. Also the 2nd level Caching used by Hibernate is of not much use if few other applications are updating the database.

For non data centric applications Hibernate is the way to go.

Regards,
Vijay
 
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sounds like you application may be doing some sort of bulk loading Vijay Kashyap. Am I right? If so, there is no ORM technology that really fits this requirement. Database-specific tools are usually the way to go


Also in our case we need to switch on and off databse indexes which you cannot control thru Hibernate.


You can. Just use a standard SQL statement, rather than HQL.


Also with the database abstraction layer you can gain extra benefits of stored procedures.


Not sure I follow this. If you use the database directly, and rely on Stored Procedures, surely there is no abstraction layer between your code and the database?
 
Vijay Kashyap
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Paul, you are right my application is heavy on data volume. Bulk inserts and updates are used which scales well if you can take extra leverage from database.

My point being there is nothing wrong in using Oracle specific (or database) features to gain that extra performance.I am supporting 5 different databases and application sqls are tuned for each one of them.

I am accessing iBatis as it gives more flexibility with sqls.

Vijay
 
Paul Sturrock
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


My point being there is nothing wrong in using Oracle specific (or database) features to gain that extra performance.


Couldn't agree more


I am accessing iBatis as it gives more flexibility with sqls.


Does it? Hibernate supports the mapping of Stored Procedures and native SQL.
[ October 20, 2006: Message edited by: Paul Sturrock ]
 
Ranch Hand
Posts: 214
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
For those drinking the sasparilla, notice that a big part of (at least some of) the Oracle guys complaints are really just expressing "hostility" to object oriented programming and n-tier architecture.

Perhaps one day if SOA completely supersedes OO, the "data guys" may seem to prove their point. At any rate, the enterprise data is most likely still going to be stored in some RDBMS.

It's always felt a little weird to me to ignore (abstract away) the underlying database when that abstraction is not a requirement.
 
Mark Spritzler
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Edward Chen:
Hi, Guys,
I have posted same question to Oracle forum.
http://forums.oracle.com/forums/thread.jspa?threadID=435466&tstart=0
You could see database person's view.

Thanks.



Yes very funny. But what I never stated, is that I have over 12 years of database experience, including 6 years as an Oracle DBA, (Completed first 2 certs, but never finished the last two, but I know it very well), writing PL/SQL, not only with VB, Java, and other languages, but also with Oracle Forms. And while, I agree you have a learning curve with hibernate. The elegance and ease of a Hibernate solution, I will always take over putting tons of stuff in the database. Let's even put aside my comment on maintenance, because while a stored procedure on its own is easy to maintain, I am talking about the whole pictures, both sides, Java and Database sides. If you make is such that it is very easy on the database side, the Java side becomes very difficult to maintain.

My one goal in IT life is to reduce the costs of maintenance (80% of your costs) while still maintaining high performance and a great user experience.

Mark
 
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
ORM faster than stored procedures is urban legend.

ORM engines add overhead on the top of JDBC and queries are not always compiled to the most performing SQL (another urban legend).

ORM engines come with caching systems where you could eventually achieve good performance comparing to JDBC or even stored procedures. This depends on the profile of your data and application. Mostly, you benefit using ORM when your data is immutable or does not change very often.

If someone says that his ORM engine outperform stored procedures, you can challenge this person.

The more you push down to database processing the fastest will be the data processing.

On the other hand the more processing is pushed down to database the less you scale (not if you have a clustered db).

Popping data from DB to Java and doing processing has its costs (mostly i/o).

All of above is purely tech, and the mind change is moving business from stored procedures to a business layer (java, .net), which, in theory, allows to quickly adapt for business changes and expose data as services to several systems.

The architectural choice from putting business data processing in java will bring several benefits that will shadow the performance loss. Systems are becoming very complex and SOA is here to stay. The goal now is no longer data centric, but distributed and available to different business units. The database server is no longer capable to head the business of large organizations.

In any case, if performance loss is not a consideration them you should consider C++. Under the scenes java uses C++ to improve performance anyway.

FYI, I'm a developer of JPOX, a JDO implementation.

Go for ORM, but be sure to understand its limitations.
[ October 20, 2006: Message edited by: Erik Bengtson ]
 
Scott Johnson
Ranch Hand
Posts: 518
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[Edwin] Perhaps one day if SOA completely supersedes OO, the "data guys" may seem to prove their point.

I don't follow your reasoning. In a service-oriented architecture, data and business logic are exposed via standard, platform-independent interfaces. SOA won't supersede OO. You can still create your services using OO methodologies (or not).
 
Scott Johnson
Ranch Hand
Posts: 518
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[Erik] ORM faster than stored procedures is urban legend. ... If someone says that his ORM engine outperform stored procedures, you can challenge this person.

Maybe I missed it, but I don't recall anyone claiming this. In fact I said the reverse: stored procedures may be faster in some situations.
 
Edward Chen
Ranch Hand
Posts: 798
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I found an article online related to this, maybe it is helpful.

http://www.onjava.com/pub/a/onjava/2003/08/13/stored_procedures.html
 
Mark Spritzler
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Edward Chen:
I found an article online related to this, maybe it is helpful.

http://www.onjava.com/pub/a/onjava/2003/08/13/stored_procedures.html



The problem again will lead to the maintenance of your Java code. Here in that article you see how many lines of code it takes to use JDBC and calling a stored procedure. Add those up to calling lots of different stored procedures and you have you maintenance nightmare on the Java side. By using a product like Hibernate, you are able to remove all that code and make it much simpler.

And if you still want Stored Procedures, you can still have Hibernate call them, with just a couple of caveats.

I am going to close this thread.

I re-opened it, but choose to further ignore the thread. Both sides need to see the need to work together. End of my posting here.

Mark
[ October 23, 2006: Message edited by: Mark Spritzler ]
reply
    Bookmark Topic Watch Topic
  • New Topic