Hmn. Good point. I feel a more important impedance mismatch is one of transactions/concurrency.

If your model is ORM OOP such as:

    user := LoadUser(db, uid)
    user.SetName("Alice")
    user.Save()

the impedance mismatch is really that the "user" you have in the memory in the backend actually isn't the real user. After doing SetName() it isn't committed to the database, other processes will still see the old name and so on.

I mean, just at the point you have loaded the user there is (I feel..) an impedance mismatch if you think about the "user" object as "the user", instead of simply "a query result of userInfo that may already be stale".

If you drop the ORM and just execute "update User set Name = @newName where Id = @uid and Name = @oldName" there is no impedance mismatch. Either you do the update or someone raced you and you did not. There is no stale data anywhere to worry about.

Perhaps OOP isn't the sole reason for the "fetch/modify/save" programming style, but I think the OOP way of thinking of the world quickly lead to that kind of solution approach.

A database supports "query" and "apply a transaction to move from one version of the data to the next version".

OOP-focused use of ORM thinks more about "loading" and "saving". That is where the impedance mismatch is I feel.

OOP => there is such things as "objects" => objects must be "loaded" and "saved" => mismatch.

If one doesn't need to fetch/modify/save, but instead things in terms of queries and transactions, then you also don't need to care about "nested structure" nearly as often. I don't use ORMs and it just doesn't come up that much -- why would I load the nested structures to the backend?..

Although I agree with what you say that there is a fundamental mismatch between the efficient way to store nested structures in backend vs DB.