[ericclemmons]

My company has a very large application that still utilizes an ORM (Doctrine).

The primary benefit is the lazy (proxy) loading of entities and mapping data onto complex graphs, not to mention updates that span multiple entities in a single transaction.

Performance-wise, we've reduced lazy loading via eager selects, result caches, and one instance of mapping SQl results back to an object.

All in all, it feels better working with objects than it does with raw data, and it is very reliable in my experience.

[spankyhoot]

this is the trouble with ORM's though - mapping things into complex graphs is anti-relational. SQL wants you to work in sets. ORM's are trying to bridge that impedance mismatch - but the real answer is to not fight it.

[ericclemmons]

I still don't see how this is the "trouble with ORMs". I haven't had any trouble with this, and we have a highly-relational, yet complex graph structure.

As a tool, it seems to work extremely well, despite academic objections to it.

[bunderbunder]

It's not necessarily that the ORM will give you bad results, it's that an ORM might be giving you sub-optimal results.

A lot of ORMs don't use more advanced querying functionality, and SQL can be a very harsh taskmaster when it comes to decisions about how to structure a query. So on an enterprise-grade DBMS it's not unheard-of for hand-coded data access layer to outperform what an ORM does by multiple orders of magnitude.

Of course a good ORM offers you a way to substitute your own queries. Unfortunately teams that rely heavily on ORM aren't necessarily cultivating strong database talent, so these kinds of heinous performance drags can easily end up going undiscovered and unfixed even though the tools to deal with them are readily available.