

ORM Haters Don't Get It - kalodim
http://www.javacodegeeks.com/2012/05/orm-haters-dont-get-it.html

======
willvarfar
Martin Fowler's recent post is far better:
<http://martinfowler.com/bliki/OrmHate.html>

------
lucian1900
The concept of ORM isn't necessarily bad, it's just that most ORMs are
terrible and try to map too much of relational algebra to objects, even if it
is a bad fit.

Good ORMs like SQLAlchemy first model a relational database and then build the
object bits on top of that. That's why you can do an explicit outer join
between models so you end up making a constant number of queries (instead of n
queries with the naive attribute fetch in a loop).

One almost never has to write SQL when using SQLAlchemy, as opposed to, for
example, Django's ORM, which has a much more "mainstream" design. SQLAlchemy
is more like a relational/SQL library + an optional ORM-like thing.

------
rhizome31
The misunderstanding largely comes from the name. Things might be clearer if
they were simply called _SQL libraries_.

------
tyuthtynj
ORM offers robustness to a _subset_ of relational database abilities, at the
cost of simplicity. That's philosophically wrong IMHO - it's too great a loss
of functionality, time and attention for replacing something I don't yet have
any need to replace.

Whilst I dare say there're applications where ORM is the only sensible choice,
I've yet to see any trace of them in my (fairly) varied experience.

------
islon
I think this guy "don't get" many things about ORM like: \- They insert a
great deal of incidental complexity in your solution. \- Most DBAs are
specialists in SQL and relational databases not OO or JPQL, etc. \- If you
have to read a 880 pages book to really understand your ORM framework there's
something wrong with it (java overengineering probably).

------
10098
Maybe if one tries to do as much as possible from within the database itself
(i.e. implement business logic using stored procedures, triggers and such, not
an external programming language), there will be no need for any ORMs
whatsoever? That's a honest question btw, I don't have much experience with
databases, just curious to know.

------
Osiris
I've worked with ORMs that make it difficult to write specific kinds of
queries, and that's usually because the ORM is designed to be robust enough.
However, even that ORM would allow you manually write a query and then run it
and it would convert the results back into lovely packaged objects to pass
around and work on.

In a language like PHP there's a lot of annoying boilerplate you have to write
around every query you run by hand like looping over the result set that an
ORM can just convert into a pretty little associative array for you with a
consistent structure.

As far as I'm aware, any ORM allows for hand-written queries, so if the
argument is that ORM-generated queries are too bloated/slow, you can still
write optimized queries where needed and still take advantage of the
automatically conversion of the result set to a useful object.

------
kriro
The main advantage as far as I'm concerned is semantic integrity. You stil get
to think and model in OOP terms.

That's valuable and good abstractions are worth some trade-offs.

Of course you also get that if you use an object database like ZODB but you
face similar trade-offs most noteably speed which is usually solved by using a
RDMS for indexing.

------
sirfried
5 mins of my life i will never get back. object mappers are good enough, write
better oop and embrace sql if you need to.

