> Another selling point which is "you don't need to know SQL"
It has never ever been a selling point by anyone with an ounce of brain.
ORMs are made for OLTP workloads, not OLAPs (one of the creators of Hibernate have also said so, but I won’t look it up now), and their primary utility is to save you from writing long and error prone insert and update queries, plus they automatically map an sql row to an object. That’s it.
You will reimplement plenty of parts of it if you go the raw way, so it is again, not a zero sum game.
> Every project I've been involved with that got saddled with an ORM was originally justified "so junior developers don't need to know SQL".
The people who made "not knowing SQL" the main reason to use an ORM should not be making the decision to use an ORM. They can only use it incorrectly.
If there are ORMs that document "not needing to know SQL" as a key selling point of their ORM, they should remove those sentences because it's not.
As someone with 15 years experience using ORMs, you absolutely do need to know how your database works to be effective at using an ORM well. Once you do, and you understand how your ORM works, I still think the benefits of a well-integrated ORM into your codebase make it worthwhile. Generally the code becomes easier to understand, modify and reuse if you're using an industry-standard ORM. Like with most good libraries or frameworks, the number of use cases the maintainers encounter usually means you'll find something pre-prepared when you come across a new problem.
To be fair, in our DAL we use Entity Framework (which is kind of just an ORM++) and a good 95% of the queries we do are just straight up linq. The last 5% which use raw SQL are critical paths we found either directly through testing or as our customers systems gradually got slower as the database grew and needed optimisation.
Eventually the Juniors are expected to learn SQL, but until such a time as they do they can still make useful contributions to the code base.
Honestly, where are they even getting junior developers that don't know some basic amount of SQL or can't learn it in an afternoon? It's such a non-issue. What a great way to ensure juniors never gain proper SQL experience/expertise, and they'll be the later senior developers too, which just propogates the problem.
Sorry to hear that you encountered such teams. It tells a lot about their professionalism and experience. There are teams which do not use this kind of argumentation.
I wish. I have it justified to me as "our SQL is not good" as the reason to use ORMs in my workplace. The result is code that primarily centers around the idea of fetching objects into memory and flushing them back to the database. JOINs are not used, you do lookup chains in Java instead. And if you need to update a field, you fetch the entire object into memory (a SELECT *), update one field and flush the whole thing back to the database. That's what an ORM gets you. A plainly wrong way of thinking about how to manipulate data for developers.
It's not that they don't know SQL. They know SQL. The problem is, the only SQL they know is fetching objects by primary key/some other condition because that's the only thing an ORM does well. The SQL table could very well be a dumb key-value store because that's all that their code treats the SQL database like.
It has never ever been a selling point by anyone with an ounce of brain.
ORMs are made for OLTP workloads, not OLAPs (one of the creators of Hibernate have also said so, but I won’t look it up now), and their primary utility is to save you from writing long and error prone insert and update queries, plus they automatically map an sql row to an object. That’s it.
You will reimplement plenty of parts of it if you go the raw way, so it is again, not a zero sum game.