“Just use SQL”, they say. “No need for ORMs”, they add. And they may be right, but… Let's look on how this can lead to accidental complexity piling on, derailing our initially simple problem.
From a backend engineer, that writes SQL for a living, sorry this is Utter garbage.Try doing group by, rownumber, dense rank, lead, lag,pivot in JavaScript . But I am so happy because of article like this, I will always have a job. And the beginners that read this article will never learn system design in their life. And will be replaced by AI early in their careers.
I’d suggest reading the full article, as it’s not against using SQL. It’s showing how blindly following blank statements like “Just do X” can escalate with accidental complexity.
I saw such things happening in numerous projects. Not only with SQL.
I read this, and I read your article In Defense of ORMs.
I am somewhat in that camp of ORM-haters that you are trying to address, but I don't think that we necessarily disagree - I suspect we may be using different definitions of what an ORM is. And maybe I'm wrong and being too narrow!
But, in my mind, ORM is a framework that tries to map object identity & lifetime back to the database. You know the classic ActiveRecord type pattern where if I have a User object and call `setEmail`, it's doing the SQL UPDATE transparently in the backend. I _do not_ hold that just any database utility framework is an ORM.
I gladly use utilities that can codegen type-safe systems around my database schema while hating on traditional ORMs, because like you I'm all-in on type safety and avoiding stringly-typing things.
To avoid complexity and keep using SQL you need something like a hybrid between ORM and SQL, something like SqlP https://dev.vvveb.com/sqlp
Yup, there are also tools like JOOQ, Dapper, etc. Also, modern database SDKs are quite accessible in terms of mappings. So there's a middle ground.
In the follow-up, I'll try to explain what I'm building with Pongo, which can be a similar example.
From a backend engineer, that writes SQL for a living, sorry this is Utter garbage.Try doing group by, rownumber, dense rank, lead, lag,pivot in JavaScript . But I am so happy because of article like this, I will always have a job. And the beginners that read this article will never learn system design in their life. And will be replaced by AI early in their careers.
But Slava Ukraini.
I’d suggest reading the full article, as it’s not against using SQL. It’s showing how blindly following blank statements like “Just do X” can escalate with accidental complexity.
I saw such things happening in numerous projects. Not only with SQL.
p.s. Also, why so mean? 🤔
I read this, and I read your article In Defense of ORMs.
I am somewhat in that camp of ORM-haters that you are trying to address, but I don't think that we necessarily disagree - I suspect we may be using different definitions of what an ORM is. And maybe I'm wrong and being too narrow!
But, in my mind, ORM is a framework that tries to map object identity & lifetime back to the database. You know the classic ActiveRecord type pattern where if I have a User object and call `setEmail`, it's doing the SQL UPDATE transparently in the backend. I _do not_ hold that just any database utility framework is an ORM.
I gladly use utilities that can codegen type-safe systems around my database schema while hating on traditional ORMs, because like you I'm all-in on type safety and avoiding stringly-typing things.