Hibernate works great for most insert, update and delete statements and for all select statements that are not too complex.
If most of your database requests require complex select statements, e.g. reporting use cases, you shouldn't use Hibernate.
I'm not sure what "complex select statements" means, but I would make a few observations:
Back before JPA, when there were several competing ORM frameworks (Hibernate, JDO, and EJB), the people at Kodo JDO (now part of Oracle) observed that it was easier to get a Java expert than to get a Java/SQL expert. By having a java-like query language, you could hire less expert talent (sometimes!)
SQL JOINS are universally regarded as It's MUCH easier to relate ORM Entity Objects than to build complex join queries.
In my webapps, where I am often working with a set of related objects, often I can interface with my high-level persistence layer using a single "anchor" object and selected relatives using an ORM, I can process them as detached objects, then toss them back to the persistence service layer as a unit (and a single transaction) instead of in parts like I would with raw DAOs. My DAOs are all lower down
Aside from saving wear and tear on programmers, ORMs are often more efficient than hand-coded SQL - I've seen benchmarks where ORMs performed twice as fast. That may not seem intuitive, but it parallels the experience with Assembly language versus high-level languages. Sure, you have more control, but it's also more work, and as you scale up, the cost of constantly rewriting code optimally with every change you make becomes prohibitive. A machine can rewrite - and re-optimize - code at the raw instruction level all day long at microsecond speeds and never get tired or make mistakes (bugs in the compiler don't count - they're other people's mistakes). AND as the current crop of JVMs has shown, a JIT code-writing environment can monitor for best/worst case and re-optimize on the fly based on workloads, whereas hard-coded optimizations are for better or worse, basically it.
Finally, there's cache. Raw JDBC/SQL offers little or no cache support. Some DBMS's such as PostgreSQL do have JDBC proxy servers that can cache for you, but not every DBMS is so well supported. Hibernate can do caching and work with external caching.
On the downside, an ORM is overkill for small projects. You have to spend extra time mapping entities, then the ORM itself is overhead. That's when I'd typically use SQL. It's when you start scaling up that ORMs begin to excel.
Loudly announcing something is true and finding out you're wrong makes you feel foolish.
Finding out you're wrong and refusing to admit it makes you LOOK foolish.
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop