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