Catchy headline, yes. But check out this Stack Overflow question by user Mike:
(I’m duplicating it here on the blog, as it might be deleted soon)
It’s a pretty open ended question. I’ll be starting out a new project and am looking at different ORMs to integrate with database access.
Do you have any favorites? Are there any you would advise staying clear of?
And the top voted answer (164 points by David Crawshaw is: “Just use SQL”:
I have stopped using ORMs.
The reason is not any great flaw in the concept. Hibernate works well. Instead, I have found that queries have low overhead and I can fit lots of complex logic into large SQL queries, and shift a lot of my processing into the database.
So consider just using the JDBC package.
The second answer (66 points by user simon) is, again: “Just use SQL”:
None, because having an ORM takes too much control away with small benefits. The time savings gained are easily blown away when you have to debug abnormalities resulting from the use of the ORM. Furthermore, ORMs discourage developers from learning SQL and how relational databases work and using this for their benefit.
The third answer (51 points by myself) is saying, once more: “Use SQL” (and use it with jOOQ).
Only the fourth answer (46 points by Abdullah Jibaly) mentiones Hibernate, the most popular ORM in the Java ecosystem.
The truth is, as we’ve shown numerous times on this blog: Hibernate/JPA/ORMs are good tools to get rid of boring (and complex) CRUD. But that’s just boilerplate logic with little value to your business logic. The interesting stuff – the queries, the batch and bulk processing, the analytics, the reporting, they’re all best done with SQL. Here are some additional articles:
- Turn Around. Don’t Use JPA’s loadgraph and fetchgraph Hints. Use SQL Instead.
- Java 8: No More Need for ORMs
- Type Safe Queries for JPA’s Native Query API
- NoSQL? No, SQL! – How to Calculate Running Totals
- 10 SQL Tricks That You Didn’t Think Were Possible
Stay tuned as we’re entering an era of programming where object orientation fades, and functional / declarative programming makes data processing extremely easy and lean again.
Many Americans believe stuff, according to this universally true source I randomly googled:
http://list25.com/25-unbelieavable-things-americans-believe/
Many of them believe it, so it’s right, isn’t it?
So, let’s all jump blindly, use your proprietary stuff, and reimplement house-made ORMs to map between our objects and jooq. Right?
Yannick, your comment was as well timed as it was expected.
However, I do invite you to join one of my SQL Masterclasses. I am convinced I will be able to show you how beautiful SQL is, and why so many other people have been upvoting the answers that encourage using SQL.
ORM tools are as great as you manage to use them properly. There are projects where ORM tools work like a charms, while in others, they don’t fit well at all. In the end, it’s the development team responsibility to choose the right tool for their project requirements.
ORM tools are complex. Unfortunately, only a part of all developers will spend time to understand how they work. The rest will just blame the tool and say it’s bad.
The question is: Does the most upvoted answer offers the best advice?
Do we really want to use plain JDBC? Why? I’d choose Hibernate or jOOQ any time over plain JDBC.
The next answer is not really true either:
Hibernate has been offering the SQLQuery API from the very beginning. In fact, [Gavin Kind (the creator of Hibernate) said it very clearly](https://www.reddit.com/r/programming/comments/2cnw8x/what_orms_have_taught_me_just_learn_sql/cjheyec):
Most of the people who blame Hibernate will blame the next data access framework if they don’t take time to master SQL, JDBC or any RDBMS-specific peculiarities.
Thank you very much for your feedback.
JDBC can be a great fit in some environments. It has zero overhead and sometimes you can easily live with string-based SQL. Perhaps, add some tiny API on top of it to ease the pain of checked exceptions and indexed bind variables and ResultSet to List mapping, but that’s it.
I completely agree with Gavin again (already had at the time). It is sad indeed. Many comments in this discussion (https://redd.it/4rc9uu) about understanding JOINs by understanding cartesian products are equally sad. A lot of people prefer to go through the path of least resistance, deferring thinking about stuff properly until much later in the project, when it’s too late to make fundamental decisions.
Which is, after all, why we do make a living as consultants and experts, though. Right? :)
Even worse, some people will just “assume” how SQL, ORM, or any other framework works and never invest time to check if those assumptions are actually true.
For all these reasons, I’m very confident that there will be a high demand for SQL, RDBMS, and Data experts many years from now. If Jim Grays’ papers from 1976 are still relevant today, there is a good chance that SQL is going to be relevant even 40 years from now.
To be fair, not everyone has the possibility (or capacity) to invest that time or actually do that check.
I’m newly baptized jOOQ believer :D
I encountered jOOQ after I changed my workplace and landed on project with jOOQ. I always had a thing for SQL. At the beginning of my career as Java dev I was that one weirdo who volunteered to do the fixes in legacy, spaghetti PL/SQL code. It was just like solving logical puzzles. Then I moved to doing less-legacy stuff and Hibernate happened. After some learning and accommodating time it was simple to use but it felt “less natural”. Although simple querying was comfortable.
Now with jOOQ simple data access is as simple as with ORM or spring-data by auto generating daos, and for more complex stuff it is for me way faster to just type a SQL (typesafe btw ;) as I know what I need from my db, than searching the net for some annotation combo to make the ORM do what I need.
Also, slightly of the topic, trolly nature of jOOQ’s creator fits my sense of humor which makes learning it quite more amusing.
You’re welcome :) About the trolling, I mean.