Consider a common tutorial for object-oriented programming languages like C++ or Java: create a simple order processing system with objects representing accounts, orders, items etc (or something more or less equivalent). Makes perfect intuitive sense, but the elephant at the dining table is that it's not real because these are in-memory objects; in a real system, accounts, orders etc don't actually live in memory in the first place, they live in a database, with the memory representation only a short-lived mirror thereof.
You could write a lot of code yourself to read and write from the database, but that's so tedious and error-prone that nobody actually does it.
Everyone ends up using an ORM, but those are so problematic in their own right that a famous paper calls them 'the Vietnam of our industry'.
I don't think that's a mismatch between object and relational so much as a mismatch between the programming language and the database being separate things that don't know about each other. Conjecture: the solution is to have a single language that is both the programming and database query language, which in turn would require that the language runtime also be the database, and the JIT compiler also be the query optimizer.
So that's the summary of the problems I see it. My question is, has anyone yet either,
Actually built such a unified system
Tried but failed to build such a unified system
Written anything substantial on the topic of how you would go about building such, or why or why not
Come up with an alternative way to solve the problem?