Losing The Fear of SQL
Why ORMs are an obstacle, and what to replace them with
ORMs are more harm than good. Everybody knows it.
They start fine—that’s one reason everyone adopts them in the first place. No boilerplate. But then there’s some special use case down the line where you yearn for the expressiveness of SQL (rather than the way your ORM forces you to write it), and there’s no way to do it.
Which is why every engineer worth their salt will tell you not to use an ORM. Even when they have one, spread throughout the software.
“Why?”
I used to ask that question too. It first started as a thought I stared at, one that had never struck me before. Software is of our own making, and if it feels like a prison, then we’re the warden.
And it’s not like this is a new problem. There’s a well-known article by Ted Neward called The Vietnam War of Computer Science in which the problems of using ORMs are described, and the fact that it uses the Vietnam War as a metaphor should tell you how long ago this article was written.
Even Steve Wozniak has written on the topic, arriving at the same conclusion: just learn SQL:
I’ve come to the conclusion that, for me, ORMs are more detriment than benefit. In short, they can be used to nicely augment working with SQL in a program, but they should not replace it.
— Steve Wozniak, What ORMs have taught me: just learn SQL
I resonate strongly with that quote. But not with the title.
I don’t think it’s a matter of not knowing SQL. Wozniak may very well think it is, but note that he wrote his software without the Internet, without Google, and, crucially, without Stack Overflow.
He wrote database queries at a time when if you wanted to do it well you needed to learn SQL.
That’s not the case anymore. Not that you would be better off if you knew SQL well (and I’ve already recommended you to pick up a database book in a previous article), but there’s enough out there to write SQL well without having to understand the language as deeply as Wozniak does.
So it’s not a lack of knowledge that people keep using ORMs against their own judgement; people already “just know” SQL.
The problem is something else.
I’m Alvaro Duran, and this is The Payments Engineer Playbook. You’re already subscribed to free newsletters that “teach” you how to get a job as a software engineer.
But you don’t want to get a job; you already have one. What you want is to learn how to be great at your job. Especially as a payments engineer, where stakes are sky-high, and the margin for error is razor-thin.
In The Payments Engineer Playbook, we investigate the technology that transfers money. All to help you become a smarter, more skillful, and more successful payments engineer. And we do that by cutting off one sliver of it and extracting tactics from it.
In today’s article, I’m going to argue that ORMs are a good thing, as long as you build them yourself. That, and not SQL syntax, is the knowledge you’re missing.
Here’s what you can expect in today’s article:
Why your own ORM trumps everything out there
What an ORM does (it’s simple, but not easy)
How to start building one (step by step)
Enough intro, let’s dive in.
