
OrmHate (2012) - wilsonfiifi
https://martinfowler.com/bliki/OrmHate.html
======
jdonaldson
I started my career out writing database applications. Every aspect of those
applications were schema-driven, and I would generally would try and solve
problems at a schema level (e.g. for rendering/presentation, etc.)

In application development, it's gotten very popular to ignore the data
storage component of application design, or at least defer it to the last
possible moment. React et al take things even further by requiring their own
modeling logic.

As many here would agree, relational dbs never went away. But for some reason
folks stopped trying to push the envelope with schema-driven application
development. I kept expecting to see iterations of schema-driven design and
layout system (using inputs derived from table fields, etc). What we got
instead is this ORM business. Is there a schema-first tooling community that
I'm unaware of?

~~~
haolez
I'm not sure if this fits your bill, but you can go pretty far into
application logic by combining PostgreSQL and PostgREST
([https://postgrest.com/](https://postgrest.com/)).

~~~
jdonaldson
I think that's a great example!

------
0x445442
Yeah, to me SQL Mappers like MyBatis are usually the way to go. I don't want
the power of SQL abstracted away from me in most cases.

If I had a nickel for every time I've seen code using an ORM framework
fetching a set of ids and then iterating over that set to fetch a single
record at a time. And then if I had another nickle for each blank stare I got
when I explained that only one SQL query was needed to return the flattened
result set of data and that the hierarchical object graph could be built in
the app much faster than the N SQL queries they were making.

~~~
twic
I really feel like i'm owed a considerable number of nickels for all the times
i've seen posts and comments about ORMs which miss the fact that they have
powerful query languages built in. JPQL is a genuinely pretty nice way of
querying a database - it's basically SQL, plus object property syntax [1].
Here's a little example which concisely examines a many-to-many relationship:

    
    
      SELECT DISTINCT p
      FROM Player p
      WHERE p.teams IS NOT EMPTY
    

Or navigation through a path (i made this example up, might not be quite
right):

    
    
      SELECT t.name, t.league.sport
      FROM Team t
      WHERE t.city = 'Ul Qoma'
    

If you're doing reporting where it doesn't make sense to pull out the
entities, you can use a constructor expression [2] to materialise results as
anything else you like (again, made up, might not be spot on):

    
    
      // package hn; public class CountSummary { public CountSummary(String name, int count) {} }
      SELECT NEW hn.CountSummary(l.name, COUNT(l.teams))
      FROM League l
    

Certainly, there are more sophisticated features of SQL that are useful for
analytical queries that aren't in this query language. That's why every ORM
has an escape hatch where you can write raw SQL, but still use its machinery
for turning results into objects.

[1]
[https://docs.oracle.com/javaee/6/tutorial/doc/bnbtl.html](https://docs.oracle.com/javaee/6/tutorial/doc/bnbtl.html)

[2]
[https://docs.oracle.com/javaee/6/tutorial/doc/bnbuf.html#bnb...](https://docs.oracle.com/javaee/6/tutorial/doc/bnbuf.html#bnbwc)

------
QueensGambit
This article focuses on ease of use i.e. avoiding the nastiness of RDBMS
entities as in-memory data structure. But the main reason most of us used ORM
is because of its portability between different databases. In the on-premise
deployment era, each customer was a Oracle/MSSQL/MySQL shop and ORMs magically
solved this problem by letting us write once and run on any database. Today,
this portability problem still exists between different cloud vendors' NoSQL
databases, even if it solves the mapping problem.

~~~
pgaddict
The downside of using ORM this way is that it doesn't really solve the
interesting cases, or more subtle differences in behaviour.

By "interesting cases" I mean applications that leverage the more unique
features in different database systems (like the full-text search
implementations, that tend to be very database specific). By subtle
differences I mean e.g. specific issues like Oracle handling NULL vs. empty
string unlike other databases, or more serious differences related e.g. to
locking (so an application that works fine on one database fails spectacularly
on another one).

Obviously, if you treat the advanced database system as a dumb data store,
this may work. But it kinda tends to reduce any database to the worst non-
existent database, missing any of the nice features. Because all the advanced
stuff is "forbidden" for portability reasons. I've seen so many cases of
performance issues where the right solutions were rejected because it would
impact portabiliy ...

~~~
QueensGambit
>> By "interesting cases" I mean applications that leverage the more unique
features in different database systems

Actually, most ORMs like Hibernate allow you to write native SQL (or even
stored procedure) to take advantage of native db features. In that case, you
have to trade-off portability, if that feature is important to you.

>> or more serious differences related e.g. to locking (so an application that
works fine on one database fails spectacularly on another one)

Locking (default - READ_COMMITTED) also works consistently across databases.
The problem happens only when you introduce distributed ORM cache where data
is not updated synchronously across the cluster. It is a reasonable trade-off
for performance.

~~~
wtetzner
Something like jOOQ allows you to use the fancy SQL features while still
keeping portability.

------
martin1975
No reason to hate ORM unless you're letting the ORM tool generate your schema,
in which case, you might get really lucky... or you might find out the hard
way that there's a fine distinction between DBAs and software engineers.

~~~
WJW
ORMs make 95% of queries/tasks simpler, but when you encounter the other 5%
the lack of "practice" regarding how the database works under the hood will
bite you in the ass.

Somehow I became the "database guy" of my workplace (small startup without a
dedicated DBA) and everybody thinks I really dislike our ORM because all they
hear me say about it is pretty negative. However, that is because nobody comes
to me with the 95% of easy questions so every question I get is one of the 5%
edge cases where the ORM is really not a good fit :|

------
scarface74
The problem I have with every ORM I've used is it feels tacked on. The only
framework that I know that treats queries like a first class citizen is .Net.
The beauty of Linq -> Expression Trees -> data store can't be overestated.

The fact that you can use the same Linq expressions in your code and they can
be translated to in memory Lists, Sql, or even MongoQuery at runtime is
beautiful.

~~~
pathartl
Agreed. I used to be on the .NET hate bandwagon because I didn't understand it
and conforming to MS was more of a business-suit idea for me. However, EF +
LINQ + expression trees are amazing.

------
vinceguidry
I don't know that a better ORM than ActiveRecord is imaginable. It's seriously
good, and getting better every year. I don't think a better DSL for database
wrangling exists, and dropping down to SQL or the intermediate representation
(arel) couldn't be easier, you can take any ActiveRelation object and call
.to_sql on it to see what it's doing.

I've used DataMapper and Sequel, and read through the ROM docs, I don't think
any of them really bring something better to the table than good, old, solid
Active Record. Linq is expressive and fun, compared to .NET. Nothing compared
to Ruby.

As abstraction layers go, I can't ask for a better one.

~~~
Ygg2
> I don't know that a better ORM than ActiveRecord is imaginable.

SQL Alchemy [https://www.sqlalchemy.org/](https://www.sqlalchemy.org/)

~~~
vinceguidry
That's a fair suggestion, as I don't use Python. My feeling is that it would
be the same as Linq, really amazing compared to the other Python alternatives,
but ultimately hampered by Python when you're trying to compare it across
languages / stacks. My distaste for Python runs somewhat deep, I certainly
wouldn't involve myself on any web project that uses it. Maybe for games.

~~~
blattimwind
sqlalchemy is hands-down the best ORM I've ever seen. It only gives you
exactly as much magic as you want (imho an annoying problem with anything
related to Django) and instead of generating SQL more or less directly it
operates on an SQL DSL, which can be extended at just the right points to use
pretty much any DB feature, including those sqlalchemy does not know or
understand.

I don't know Linq personally but I know people liking it very much -- your
comparison is probably accurate.

------
projectileboy
My problem with ORMs is that they feel like overkill for small apps, and they
merely get in your way with large apps. And I have yet to be on a project with
Hibernate where they were using the caching and really understood what they
were doing.

~~~
edejong
Well, I once worked on a 1 MLOC (as far as that’s relevant) high school SaaS
administration system providing services for a large chunk of the Dutch
market. Hibernate, EHcache and cache synchronization across applications (with
an Electronic Learning Environment) all worked well. The team of 12 developers
with a small minority had expert knowledge in Hibernate and cache management.

The biggest problem I often see in large DB systems is the lack of proper
normalization, leading to very wide tables and subsequently causing
performance problems (both due to reduced scanning speed and ORMs tendency to
just pull in all attributes of selected rows).

Another problem with Hibernate is the proper demarcation of transactional
boundaries, causing DB inconsistencies. Very important to get right.

I could go on, but then this would become a blog post. In any case, I feel
that a functional mapping over the SQL AST and result sets using Scala and
Slick (for example) leads to much higher versatility, places computation
closer to storage and provides better abstraction possibilities. This, in
turn, reduces the complexity of the middle layer.

~~~
wwweston
> a small minority had expert knowledge in Hibernate and cache management.

How does Hibernate as a project (or the community around it) develop people
who have expert knowledge in it and/or general cache management?

~~~
edejong
It doesn’t! Most was self taught by reading sources and some O’Reilly books.
Community support was rather marginal at the time when true technicalities
were discussed. Same as Stack Overflow now: loads of people with superficial
knowledge, but very few with in-depth or architectural technical prowess.
Unfortunately, those ppl are often too occupied to scan the SO posts and a
simple answer skimming the true ideas often wins the accepted answer instead.

------
mildavw
Love this. What I've seen lately, as a contractor at several different
companies, is inexperienced devs getting a very long way building apps without
knowing what's going on with their database under the hood. That's a testament
to the value of ORMS.

It's common, then, that the low hanging fruit for a contractor coming in to
improve performance is to optimize queries and/or introduce triggers, views,
and stored procedures. I've found that devs are scared of plain old SQL but
the ones who know their ORM well can learn SQL easily with a little nudge and
some guidance.

------
corpMaverick
It is futile to try to hide the relational model. Now days, I think it needs
to be embraced.

~~~
mistrial9
'futile' is a false wall.. maybe common rational talk has been polarized by
entrenched interests in a technology .. BUT single column and/or schema-less
has shown its raw power, without a doubt

------
ken
> In the 90's many of us (yes including me) thought that object databases
> would solve the problem by eliminating relations on the disk. We all know
> how that worked out.

What am I supposed to know about this? I've only used an object database for
one serious (>100KLOC) project, but it was by far the best part of that
system. I always wondered why that architecture never caught on.

The only reason I'm not using an ODBMS on my own projects today is that
there's no good open-source one, but that seems like something a company could
do something about, and a lousy reason to condemn an entire architecture.

~~~
anonetal
OrientDB is a good open-source database that exposes a primarily object data
model (the document and graph abstractions are built on top of it).

Lack of a good query language and scalability issues doomed those. Mike
Stonebraker ([https://blog.grakn.ai/what-goes-around-comes-
around-52d38ee1...](https://blog.grakn.ai/what-goes-around-comes-
around-52d38ee1ea9e)) had a nice summary in that article.

~~~
ken
There are 4 reasons proposed for the failure of OODBs, in that paper, but
scalability is not among them.

Interestingly, the issues are largely C++-specific (and I know lots of people
using an ORM today but none via C++), and largely driven by historical
accident and market forces ("It is interesting to conjecture about the
marketplace chances of O2 if they had started initially in the USA with
sophisticated US venture capital backing").

I still don't think these sound like good reasons to dismiss the architecture.

------
sjclemmy
Good article. I’m currently using Entity Framework in .net and I’ve designed
the latest bit of software I’m developing by using the balanced approach
advocated here; the modelling and the RDBMS are both part of the system and
have their own constraints one has to bear in mind. After working with EF
there’s only one thing I couldn’t express that I can do in SQL and that’s have
multiple parent keys in the parent table to represent relationships with
multiple children. It took me a while to work out and I believe it is possible
in .net core.

------
commandlinefan
> deal with the object/relational mapping problem by writing their own
> framework

Now, instead, everybody deals with the object/ORM mapping problem by writing
their own framework.

------
shujutech
I'm moving my ORM into a real database, anyone interested to join me? Need
anyone with major in DBMS, able to write SQL parser and database
storage/organization. We'll be selling data model instead of database when
completed. Check us out at:
[http://shujutech.mywire.org/corporation?goto=ormj](http://shujutech.mywire.org/corporation?goto=ormj)

------
alexandercrohde
I don't get it. Firstly, is this being cited in sincerity, or to point out
"Look, even Martin Fowler advocated for NoSQL back in 2012"?

If it is entirely in sincerity, I don't understand why he thinks queries isn't
the de-facto solution. Perhaps his implicit assumption is that the database
should be structured to reflect the code, when really the code should be
structured to reflect the database?

