I see what you mean. I thought he was mocking the idea of wrapping the old uncool relational model in a fashionable new OO API.

What is substituted is not the relational DBMS but the relational model. ORMs are supposed to let you think in terms of objects instead of sets of tuples.

No, turns out most sql work involves extracting data from the resulting sql statement into objects. So you don't end up passing 5 params from the sql result everywhere.

ORMs do these automatically, and go beyond.

That's true for some basic CRUD operations and that's what ORMs should be used for.

But people tend to just blindly copy everything into an object model and perform operations on those objects that could just as well have been done in a set oriented way with a lot less code causing a lot less network traffic.

Obviously there are scalability downsides and not everything is easier to express in terms of sets, so I try to be pragmatic. You can of course do set operations through an ORM but that's not its purpose and the performance implications are sometimes tricky.

Most orms have something equivalent to HQL/LINQ. HQL allows you to use set operations, which then gets translated into its equivalent sql statement. Thus no extra objects get transferred across the network.

However there is one thing, most ORMs by default transfer the whole object. What is you only need a few variables?