The thing I learned from working with EntityFramework (aspnet) and Django ORM is that people don't really care to learn how those ORM work, they (the devs) ended up generating utterly unoptimized queries, from adding unnecessary inner joins to loading a ton of nested tables. I'd say for both ORM I mention you can pretty much have total control to tailor your sql to your needs (and still have the benefit of easier refactor).
Ofc in the end a raw sql string will always give an edge (see Dapper).
When your next project runs in a different framework or language, you'd be using a different ORM. It feels like a waste of time learning ORM. Plus it's difficult to optimize.
In 2 past jobs as a non ruby person in ruby shops i was trying to convince them to write raw sql queries instead of relying on activerecord, but with no luck. I won’t argue about performance but most of the times didn’t even know what and how many queries were being generated..
There has to be a really good reason for that.
It's just like joining a Spring shop and telling everyone to not use JDBC (or whatever the name of the ORM in Java land)...that's not gonna fly well usually. For a good reason imo.
The good reason was that queries were not optimal and when we came up with optimal ones which were not following the access pattern or syntax that activerecord introduces, then the excuse was “…but activerecord…”.
If i was a dev i would appreciate some data guy’s opinion in queries, indices, etc while my db crashes every now and then, but it’s either a power play/politics thing to ignore the new guy or the ‘i know activerecord/hibernate/kafka/whatever’ thing and i won’t bother sith anything else that will solve the problem.
It's a tradeoff.
Everything is a tradeoff...I think ORMs like ActiveRecord do make the code easier to reason about in most cases and are worth the performance hit.
All abstractions cost us performance..we could be all writing on bare metal C/C++ but not many web shops want to do that.
