
Why use an ORM? - rogerthat_au
http://blog.langoor.mobi/why-use-an-orm/
======
DigitalSea
There are two sides of the argument and both have valid arguments. An ORM
abstracts a lot of complexity when it comes to mapping tables, joins and sub-
queries so if you don't understand the underlying SQL queries your ORM is
performing and something breaks, you're at the mercy of the ORM to provide you
with adequate error messages and means for debugging. The way of looking at an
ORM is it is a framework for your database much like jQuery is a framework for
Javascript and Rails is a framework for Ruby. You can get by using the
framework but run the risk of not understanding the underlying structure and
you're screwed if the framework you're using (or ORM) is no longer updated or
works with your particular version of MySQL or whatever.

Having said that, if you're using an established ORM like Doctrine then the
possibility of ever needing to understand the underlying database structure
and complexities is almost null. The time saving benefits, pooling, support
for transactions, security best practices for your queries and caching
features alone make an ORM worthwhile in the end. I think ORM's are great if
you dig deeper and explore how the ORM works, it doesn't mean you have to
write straight-up queries, but it pays in-case you are ever in a situation
where an ORM isn't allowed by a manager or senior developer and you're asked
to write a native query.

~~~
sheraz
I've completely left ORM-land (in PHP). I find that:

    
    
      * I have little need to switch databases
      * ORMs provide little support for things like
        views, stored procedures, custom types
      * I like to see the SQL in context of my code.
    

I've come to these conclusions for myself after having run the gauntlet of
several Symfony projects. There was simply too much abstraction from the
actual code that "did the work." I found myself creating and extending classes
(or annotating) to simply add a type or make code do simple joins.

~~~
bunderbunder
I too have left ORM-land (in C#). I found that the first two of your points
are absolutely true. I've also found that if you know how to code a clean,
well-factored data access layer then it doesn't necessarily even take a whole
lot longer than wiring up an ORM does for non-trivial cases.

I also found that using the ORM was having a detrimental impact on performance
and scalability in a subtle way that had nothing to do with the ORM itself:
It's that I got used to operating so far from the database layer that I wasn't
really aware of what was going on down there. Last time I did a conversion of
a project away from ORM, the number of forehead-slapping moments when I
noticed a simple way to improve an operation's performance by at least one
order of magnitude was downright embarrassing.

That said, that's where I depart on the third point. I've also moved to using
stored procedures for everything. I don't know if the situation is quite the
same for MySQL users, but in Microsoft-land the amount of tooling SQL Server
and SQL Server Management Studio provide to help with managing, analyzing, and
refactoring SQL code is really pretty impressive. . . and if you divorce your
SQL code from its native environment by demoting it to being nothing more than
string resources that are subservient to the application code, you're letting
go of a lot of those tools. Or at the very least, creating a lot of
unnecessary friction when it comes to getting at them.

However, as a RAD kit I think ORMs are fantastic. They can, as the article
highlights, do a lot to protect someone with limited skills in database work
from getting themselves into trouble. But they're still just a RAD kit, and
like any RAD kit they have their limitations.

~~~
sheraz
Can you expand on your preference to put everything into stored procedures?
I'm increasingly curious about this because I find I'm writing more procedures
in postgresql. Or perhaps you can refer to a book/link?

And this is the third time this week I've had someone laud the benefits of SQL
Server dev tools.

Thanks.

~~~
bunderbunder
Some examples off the top of my head:

If you use server-side code, then it becomes possible to do the DRY thing by
factoring common elements out into sprocs and UDFs that can be reused by other
sprocs and UDFs.

If your procedures are already in the database then it's a lot easier to go
through and systematically evaluate how all the queries are performing as a
maintenance task (to check for missing or unused indexes, for example).

Sprocs are a heck of a lot more testable than DSQL. Unit testing suites for
SQL are generally designed to work with sprocs.

Some folks complain that sprocs tightly couple you to your DBMS. Personally
I've found that switching DBMSes is rare. If you're doing it with any
frequency, that's probably a symptom of deeper problems. And if you're using
anything more advanced than what was in the SQL '92 standard (I sincerely hope
you are - a lot of good stuff has happened to most RDBMSes in the past 20
years) then tight coupling to the database server is inevitable. On the other
hand, what's comparatively much more common is schema changes. And tight
coupling of your application to the database schema is easy to avoid with the
help of stored procedures.

~~~
sheraz
Thank you for the excellent reply.

------
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.

------
hamburglar
Maybe I'm misunderstanding, but these seem like terrible reasons to use an ORM
and good reasons for learning how to use a database. The purpose of the ORM is
to provide a more convenient way of getting stuff done, not "cover up details
so I don't have to understand them."

