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.
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.
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.
There is nothing new here. A DBA does not like that a database is subjectively misused, and then gets pissy and arrogant about it. E.g., "You’re just being lazy or scared of SQL." I'm not a fan or O/R-Ms myself but I do not feel compelled to shout it from the rooftops. shrug
Yeah... I am on the same side of the fence as the author but I've also had very little success at evangelizing SQL and stored procedures to OO devs, so I've pretty much stopped.
One point that I do think makes sense is where he says "just use flat files". Not that I'd actually advocate that, but if you're going to completely paper over the set-oriented nature of your data store, why not use a "NoSQL" (key/value) database and be done with it.
I'm not a DBA, however I will protest that I've spent enough time in the trenches to have seen both sides. To me the appeal is a more object orient abstracted view of the data. I'll also admit that it is a far from perfect solution. As a developer I find myself spending hours debugging simple problems due to misconfiguration of Hibernate. I also find performance problems often, and the configuration sometimes struggles with more complicated queries. From a dba view point I hate that adding foreign keys will destroy any functionality (at least with Activerecord/NHibernate in C#) I've used Linq->Sql which is a bit better from a configuration (and performance) point of view, but still has many problems. The problem is a perfect solution just doesn't seem to exist at the moment.
I'm on the programming side of this issue (as a matter of skills and experience) but find myself in agreement with the author. I frankly never took the time to gain the deep understanding of relational technologies -- a singular exception to my usual approach to software which is to read primary sources and gain fundamental understanding. (This is something that I have recently started to remedy.)
Perhaps its the inevitable corporate association of an RDBM that lends the subject an unattractive image in the mind (as opposed to a sexy new language, framework, or paradigm)? I am frankly at a loss to explain this to myself, given that the theory, technology, and applications of the subject are certainly quite interesting and challenging!
It's like one people saying "I don't want to use guns, because they are difficult to understand and I can do bad things with them."
Meanwhile, the people who are taking the time to learn about and use guns are dominating the world.
Any developer worth his salt will understand how to do SQL Statements to get back the right dataset or perform the correct updates. Harping on the benefits of an ORM is a bright red flag in my book, because none of them are better than the power, performance, and flexibility of actually understanding SQL. If you concentrate on learning the ORM, then you are learning yourself into a box and won't even know that there are great things outside it if you had only spent the time to learn SQL.
First of all, you can't do ORM without knowing SQL it's an inherently leaky abstraction and that's not changing anytime soon.
Using SQL is great except what do you define as 'SQL'. Is it MySQL, Oracle or Postgres? How do I migrate between them? Forget data migration, I'm just talking about the data model and constraints. Today I run my app on MySQL but tomorrow the environment will demand Oracle.
I have an app that can run on any database that Hibernate supports with zero code changes and 1 line in a config file including my data constraints.
This author doesn't know ORM, plain and simple. ORM has serious limitations and we can all agree that it sucks some of the time but a lot of the suckiness depends on the tool. If you use a crummy ORM expect crummy results. I could go on for pages and pages about what a good ORM can do but I'll just try and sum up my experience with Hibernate.
On the whole Hibernate is awesome. Yes, it has it's warts and it's very complex sometimes but once you make it a part of your infrastructure it's fantastically good. Using Hibernate with sane session management and second level caching gives on the average much better performance than would otherwise get on of hand written SQL. A good hibernate caching strategy can keep you from hitting the database at all and the best part is you just turn it on and go. If you need more performance you can use views and stored procedures for the maybe 1% of cases that can benefit from them.
Lazy initialization is a godsend for complex object graphs and HQL makes complex joins extremely readable and a breeze to write.
.
The biggest knock I have on Hibernate is that it's so easy to use poorly. No matter how much documentation is on the Hibernate website people insist on using it poorly.
As I understand it, the classic use case for an ORM is for consultingware that must be installable on multiple engines with as little duplication of work as possible. A product may have seven customers, each with highly customized requirements, (mostly) using the same engine underneath but attaching to both Oracle and MSSQL, then one day finding out the sales team has us subcontracting for IBM and it needs to be ported to DB2...
I really don't think corporate programmers have a problem with sql but more so TSQL or pl-sql. I think they intuitively have a problem with what is essentially a wrapper language for sql that is using 30 year old language technology (procedural programming). I have been in multiple environments with several thousands of stored procedures, many of them thousands of lines long. There is so much boilerplate in tsql and pl-sql that any self respecting programmer will hate it. It doesn't help that most DBAs are really not data gurus but rather vendor gurus either :/
13 comments
[ 3.0 ms ] story [ 37.3 ms ] thread1) 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.
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.
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.
One point that I do think makes sense is where he says "just use flat files". Not that I'd actually advocate that, but if you're going to completely paper over the set-oriented nature of your data store, why not use a "NoSQL" (key/value) database and be done with it.
Perhaps its the inevitable corporate association of an RDBM that lends the subject an unattractive image in the mind (as opposed to a sexy new language, framework, or paradigm)? I am frankly at a loss to explain this to myself, given that the theory, technology, and applications of the subject are certainly quite interesting and challenging!
Meanwhile, the people who are taking the time to learn about and use guns are dominating the world.
Any developer worth his salt will understand how to do SQL Statements to get back the right dataset or perform the correct updates. Harping on the benefits of an ORM is a bright red flag in my book, because none of them are better than the power, performance, and flexibility of actually understanding SQL. If you concentrate on learning the ORM, then you are learning yourself into a box and won't even know that there are great things outside it if you had only spent the time to learn SQL.
Using SQL is great except what do you define as 'SQL'. Is it MySQL, Oracle or Postgres? How do I migrate between them? Forget data migration, I'm just talking about the data model and constraints. Today I run my app on MySQL but tomorrow the environment will demand Oracle.
I have an app that can run on any database that Hibernate supports with zero code changes and 1 line in a config file including my data constraints.
On the whole Hibernate is awesome. Yes, it has it's warts and it's very complex sometimes but once you make it a part of your infrastructure it's fantastically good. Using Hibernate with sane session management and second level caching gives on the average much better performance than would otherwise get on of hand written SQL. A good hibernate caching strategy can keep you from hitting the database at all and the best part is you just turn it on and go. If you need more performance you can use views and stored procedures for the maybe 1% of cases that can benefit from them.
Lazy initialization is a godsend for complex object graphs and HQL makes complex joins extremely readable and a breeze to write. . The biggest knock I have on Hibernate is that it's so easy to use poorly. No matter how much documentation is on the Hibernate website people insist on using it poorly.