[spockz]

Databases mostly cache the right things with the right indices and execution plans.

I don’t see how the push for OOP and ORMs has anything to do with databases not caching.

Are you suggesting we move application logic down into the database engine with the last paragraph?

[cmrdporcupine]

I'm saying the line between the two is largely of our own making. The push towards OO and component models meant a strong separation between the two layers -- this was and is accepted as the "right" way to model things. But it comes with the cost of leaky abstractions, potentially broken isolation models, and high non-essential complexity by nature of the constant transition between components.

If it wasn't for this, we could be looking at DB architectures in which application logic co-habits with the DB. This doesn't imply application logic in the DB, but means that the DB's view of the data moves its way up into the application. Where the logic gets execute isn't as much the concern as what that logic operates on and that the data isolation model is consistent.

I am also of the opinion that the relational model, with its predicate-logic view of the world, is a richer way to model information than objects. So that's my bias.

A lot of this is straight out of the "Out of the Tarpit" paper, FWIW.

[nextaccountic]

Something like Hibernate in Java will fetch data from the database once, populate objects (potentially making cycles and complex relationships between Java objects), and then let your business logic deal with those long-running, persistent Java objects (as opposed to objects that you deallocate right after being done with then after you queried the database)

This means that if you ever happen to use this object again in another context without making a new query, you risk dealing with stale data. And this happens all the time, because querying the db is seen as "expensive" and reusing model objects is "cheap"