But they do. They work every freaking day, in millions of applications, all over the world.
I think it would be more correct to say "ORM's can't work perfectly for every conceivable scenario involving an RDBMS". But they certainly can, and do, work for many, many use cases.
They are trying to map from the world of sets into the world of graphs. Sets are more expressive, so there is always a good chance that there will be a lossy transformation.
But if you started with a graph, transform it to the more expressive set world, then transform it back to a graph, why would you lose anything? And in my experience that's usually the way ORM's are used... to persist an object-graph and then query/retrieve parts of that graph.
Now if you're taking an existing schema, developed for different usage patterns, and trying to layer on top of it with an ORM, then, yes, you should expect problems.
We need relational programming languages.
That's an interesting idea. What would such a language look like?
But they do. They work every freaking day, in millions of applications, all over the world.
I think it would be more correct to say "ORM's can't work perfectly for every conceivable scenario involving an RDBMS". But they certainly can, and do, work for many, many use cases.
They are trying to map from the world of sets into the world of graphs. Sets are more expressive, so there is always a good chance that there will be a lossy transformation.
But if you started with a graph, transform it to the more expressive set world, then transform it back to a graph, why would you lose anything? And in my experience that's usually the way ORM's are used... to persist an object-graph and then query/retrieve parts of that graph.
Now if you're taking an existing schema, developed for different usage patterns, and trying to layer on top of it with an ORM, then, yes, you should expect problems.
We need relational programming languages.
That's an interesting idea. What would such a language look like?