Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

When not to use Hibernate?

 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I have read great reviews about hibernate and wanted to know, in what scenario(s) is hibernate NOT suitable?
I have read list of advantages of hibernate and frankly its made to sound the best thing out there..but, as with any technology or tool, there are some scenarios when it should not be used. I am interested in knowing if any such scenaio does exist for hibernate.

thanks in advance,
parag
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My opinion, Hibernate could be a over kill when there are few tables in the system.
 
pascal betz
Ranch Hand
Posts: 547
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
batch processing of loads of data:
http://blog.hibernate.org/cgi-bin/blosxom.cgi/2004/08/27#batch
 
Gavin King
author
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
(1) don't use ORM (or Java) for processing data in bulk, if you can possibly avoid it. A stored procedure will be much faster.

(2) You don't need to use ORM if you have an application without an object-oriented domain model, and without business logic that would benefit from one. (You can still use ORM if you *like*, but you don't *need* it.)

(3) You don't need ORM if you only have 4 database tables ;-)

(4) You might run into problems if you have a *really* insane legacy schema with no referential integrity and really Bad Things all over the place. Hibenate (esp. Hibernate3) can handle *most* legacy databases very elegantly - but I have seen some truly awful things that cause problems.
 
Christian Bauer
author
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is always a way to get some functionality inside Hibernate or to fall back to a JDBC connection if needed, i.e., there is almost nothing you can't do with it in 3.0/3.1. Hibernate is not appropriate if you have to use these special features all the time in your particular system architecture. There is no hard and fast rule here, its up to you to make the decision based on many individual factors. A good list to ask yourself is in Hibernate in Action in chapter 1 and summarized in this blog entry: http://blog.hibernate.org/cgi-bin/blosxom.cgi/Christian%20Bauer/relational/comparingpersistence.html
 
Gavin King
author
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oh, I forgot:

Don't use ORM if your entire data model is hidden beneath a layer of stored procedures.

You *can* use Hibernate3 if the stored procedures are only used for CUD, and not for querying.
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks everyone for your replies. It really helped. My next set of questions might be related to migrating a 'stored proc-ed' domain model to hibernate

Parag
 
Badal Chowdhary
Ranch Hand
Posts: 34
Eclipse IDE Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Adding to an old thread. Wanted to add 1 more scenario. If your application queries large volume of data and then processes it, Hibernate could slow down processing and could lead to memory issues. Because internally it binds each db record to an object and loads the entire resultset into a collection in memory. I was processing approx 200K records i.e. querying from database and creating a proprietary file. Using Spring JDBC gave a much better performance.

Keep learning...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic