Well, the problem in ORM is the O. Objection-orientation is just a worse way to organise your data and logic than relational algebra.
It's just a shame that many languages don't support relational algebra well.
We had relations as a datatype and all the relevant operations over them (like join) in a project I was working on. It was great! Very useful for expressing business logic.
The problem in ORM is the M, the mapping is always lossy and a leaky abstraction.
Yes. So if you have the same thing in both the database and in your program, you don't need no mapping.
And I suggest that having relations in both places is the way to go.
It's not enough, there is no way to represent some db stuff (not relational, more impl oriented) or some special queries in the program with an ORM. No ORM I have seen comes close to 100% of what you could do with the DB. So still the best way to get closest to the db is using raw queries in the program, but of course that does not scale with more tables, does not scale with more db engines, and does not scale with juniors taking over your codebase and not understanding it.
So to conclude, objection-orientation is fine and relational is fine too, the issue is that the optimal way to translate between them does not scale.
I'm with the first part of your comment. But why do you suddenly conclude that object orientation is good?
If your language supports relation, there's no need to badly translate to objects. (And even if your language doesn't support everything your database does, there's still less of an impedance mismatch if you use an 'RRM' instead of an ORM.)
Reasons: - I can compose queries, which in turn makes them easier to decompose - It's easier to spot errors - I avoid parsing SQL strings - It's easier to interact with the rest of the code, both functions and objects
If I need to make just a query I gladly write SQL