ORM: Where It Hurts?

ORM (Object Relational Mapping) is still a hard task. The whole of IT industry and the computer science academia have been after it for many decades. We have been able to develop some tools to hide the difficulty and also the cumbersomeness under the hood.
Things look apparently smooth till something breaks and you have to resort to manual mode. The unsightly spectacle of object attributes and columns been stitched together in a chaotic way does not give one any confidence.
We have hardly spent any time in recreating the complexity, starting from an apparently easy problem of finding matches between object attributes and table columns. The following mapping problem is easy to solve:

Once the Java class grows a bit, we have a crisis on the relational side:

So a mere homogeneous array could trip the juggernaut of ORM! It was as easy as that!
The above scenario can be mapped by ORM. But the amount of effort involved for a single attribute makes one lose faith in the efficacy of the entire approach. Here is what you need to do on the relational side:

So much ado about a petty thing!
The next major hurdle is, usually nested object mapping.



That's a simple class hierarchy, arranged top to bottom to aid readability.
Perhaps even the above looks simple. The hierarchy is multi level and hence deeply nested. But in the OOP world, that is but a common occurrence. ORM or any other mapping system should be able to handle that.
From nature to man-made institutions, you have hierarchies everywhere. Still, repeatedly, men strive to build flat structures to model reality. E.F. Codd was definitely not the first one. Karl Marx preceded him.
June 8th, 2022