Hacker News Reader

Comment by QueensGambit | Hacker News Reader

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.

View on HN

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

It's a tradeoff, though. For 99% of LOB applications the odd details of specific database implementations are irrelevant and can be ignored by even a team of mediocre developers. Most businesses are mostly interested in selling 5-10x the number of licenses for 1.1x the cost. (Or, like the sibling comment pointed out for 0.9x the cost because you can usually ignore much of the annoying boilerplate) Performance frequently is more than "good enough" and in the 1% case where it isn't, most ORMs will let you write custom SQL (or, you can always write it outside the ORM). Sometimes the best and cheapest solution to performance problems is to simply throw more hardware at it. IME, most developers are terrible at writing queries with or without an ORM.

There are certainly use cases where ORMs are not appropriate at all but the ability to evaluate your situation and recognize the tools that are appropriate and those that are not is an important skill in the software industry in general and is not limited to ORMs.

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

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

"Most of us"?

I've never worried much about portability, but i've really appreciated an ORM saving me writing all the tedious boilerplate for turning ResultSets into objects, and objects back into parameters to update statements, particularly when changing collection properties.

A data mapper can do that just fine. You only need an ORM if you’re trying to model the relations.

The biggest advantage I see is maintennability. After years of ORM, I have to say that result is less effort to keep as not complete mess then the older way - which tended to end in much more horrible state.

Reply on news.ycombinator.com