My personal experience building two startup consumer websites has been that ORMs have been a mistake. Perhaps in enterprise environments where you have a large IT staff and want to isolate DB specifics and the whole data access layer ORMs may make sense. But for a nimble startup with a small number of talented programmers I think ORMs hurt more than they help for a couple of key reasons:
1) performance matters immensely to user experience and I can hand write much better SQL than any ORM I have seen can generate. Additionally I find it easier to predict how well my SQL will perform than to predict how the SQL generated by my ORM will perform.
2) I will likely never switch databases during the lifetime of my company and so switching SQL dialects is not a problem I face.
3) There is an impedance mismatch between tabular data stored in databases and object graphs that most ORMs represent.
4) The specifics of every ORM I've tried always left something to be desired. Hibernate was wicked complicated. Django didn't support multiple databases, SQLAlchemy was error-prone. I'm sure these specifics will get fixed over time, but for me they've just provided further disincentive.
I like to say that the two biggest mistakes I've made when building websites are using an ORM and not using an ORM.
At my current position, we're using entirely hand-coded SQL. It's been a real pain, particularly when trying to fetch large graphs, or when changing the schema.
I read articles like this and wonder if I'm missing something about SQL. I repeatedly find myself writing a whole lot of joins, and writing a tedious converter to map it to something the front end deals with. When I get sick of that and don't care about performance, I do a query for each table. Neither of those seems like the right solution.
The best solution I have found is a hybrid solution -- ORMs for fast, common operations, and SQL by hand for special or highly complex operations.
It also depends on the ORM you use. At my last full-time gig, a manager became persuaded that the ORM should be used literally _everywhere_. They gutted the stored procs I had written and replaced it all with CakePHP ORM. The result is a program that takes twenty seconds minimum to generate a page; some loadtimes would extend over three minutes.
Cake's ORM is not impressive as far as I am concerned and it's quite slow; if that's the ORM you're using, I think you're better off using SQL almost everywhere. SQLAlchemy seems to have good, tunable performance, though I've also encountered more than my share of strange errors and anomalies with it.
The other downside is that in most cases, it's a _lot_ of work to learn the specific syntax associated with an ORM well enough to allow one to perform a complex query. Many ORMs barely support complex or important DB operations, yet they have adherents who demand insane compliance with ORM implementation.
Even ORMs that are touted as "simple" or "easy" are usually not simple or easy, and of course, the people involved in those ORMs get really, really pissed off if you suggest that docs should improve or errors shouldn't happen as often or whatever.
It's just about getting a programmer with good judgment. Some tasks would benefit from a good, tunable ORM. Many wouldn't. As far as you've written in an ORM, converting between DB engines is that much less work, so it's worth it sometimes. You just have to be sane about it and I think it all ends up okay.
Comments
My personal experience building two startup consumer websites has been that ORMs have been a mistake. Perhaps in enterprise environments where you have a large IT staff and want to isolate DB specifics and the whole data access layer ORMs may make sense. But for a nimble startup with a small number of talented programmers I think ORMs hurt more than they help for a couple of key reasons:
1) performance matters immensely to user experience and I can hand write much better SQL than any ORM I have seen can generate. Additionally I find it easier to predict how well my SQL will perform than to predict how the SQL generated by my ORM will perform.
2) I will likely never switch databases during the lifetime of my company and so switching SQL dialects is not a problem I face.
3) There is an impedance mismatch between tabular data stored in databases and object graphs that most ORMs represent.
4) The specifics of every ORM I've tried always left something to be desired. Hibernate was wicked complicated. Django didn't support multiple databases, SQLAlchemy was error-prone. I'm sure these specifics will get fixed over time, but for me they've just provided further disincentive.
I like to say that the two biggest mistakes I've made when building websites are using an ORM and not using an ORM.
At my current position, we're using entirely hand-coded SQL. It's been a real pain, particularly when trying to fetch large graphs, or when changing the schema.
I read articles like this and wonder if I'm missing something about SQL. I repeatedly find myself writing a whole lot of joins, and writing a tedious converter to map it to something the front end deals with. When I get sick of that and don't care about performance, I do a query for each table. Neither of those seems like the right solution.
The best solution I have found is a hybrid solution -- ORMs for fast, common operations, and SQL by hand for special or highly complex operations.
It also depends on the ORM you use. At my last full-time gig, a manager became persuaded that the ORM should be used literally _everywhere_. They gutted the stored procs I had written and replaced it all with CakePHP ORM. The result is a program that takes twenty seconds minimum to generate a page; some loadtimes would extend over three minutes.
Cake's ORM is not impressive as far as I am concerned and it's quite slow; if that's the ORM you're using, I think you're better off using SQL almost everywhere. SQLAlchemy seems to have good, tunable performance, though I've also encountered more than my share of strange errors and anomalies with it.
The other downside is that in most cases, it's a _lot_ of work to learn the specific syntax associated with an ORM well enough to allow one to perform a complex query. Many ORMs barely support complex or important DB operations, yet they have adherents who demand insane compliance with ORM implementation.
Even ORMs that are touted as "simple" or "easy" are usually not simple or easy, and of course, the people involved in those ORMs get really, really pissed off if you suggest that docs should improve or errors shouldn't happen as often or whatever.
It's just about getting a programmer with good judgment. Some tasks would benefit from a good, tunable ORM. Many wouldn't. As far as you've written in an ORM, converting between DB engines is that much less work, so it's worth it sometimes. You just have to be sane about it and I think it all ends up okay.