Closed. This question needs to be more . This question needs to be more focused . It is not currently accepting answers. Want to improve this question? Update the question so it focuses on one problem only by editing this post. Closed 3 years ago. Improve this question

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,