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.