

O/R-Ms: Panacea or Polio Braces - peschkaj
http://facility9.com/2010/01/05/or-ms-panacea-or-polio-braces

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

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

~~~
fnid
ANSI SQL and configuration changes everywhere you need them to be flexible.

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

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

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

------
z8000
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_

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

------
ww
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 :/

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

------
lucifer
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!

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

