[nupark2]

> Assuming your are using some OO language then you will have to, at some point, turn the relational data into objects. At that point you are always creating an ORM.

This is not true.

At some point, you will need to extract a subset of the relational data and represent it using your application's in-memory model. If your hand is not forced by the ORM, this is unlikely to be a direct mapping of the database.

This is no different than a network protocol, wherein the protocol is not a direct representation of application state, and the application does not attempt to model the network protocol using the same constructs that it uses to model its in-memory state.

[drumdance]

I don't see how ORM forces your hand to be a direct mapping of the database. To me the benefit of ORM is that, most of the time I do want a direct mapping of the database, but there are often times when I need to add a layer of abstraction/validation/redirection on top of it.

[nupark2]

The direct mapping of the database that it provides isn't really direct, and the impedance mismatch makes a mess of what could be a simple, easy to understand in-memory application model.

[nahname]

"At some point, you will need to extract a subset of the relational data and represent it using your application's in-memory model."

...and that is where you have just created an ORM. You don't need a library to be using an ORM. Change 'extract' to 'map' and the meaning is the same.

[nupark2]

No, you haven't. If your in-memory application model mirrors your database model, you're probably doing it wrong; either your application model is poor, or your database model is.