What ORMs have taught me: just learn SQL (2014) • Hacker News Board

Re: What ORMs have taught me: just learn SQL (2014)

#101

Post by runevault » Sat, Jul 04, 2026, 5:09 PM UTC

geophile wrote: post #97

I used to love ORMs so much that I built one for Java, in the early 90s, and it was one of the main offerings of a startup that I joined. I have come around 180 degrees. My rethink started when a developer at a Wall Street bank said: having Oracle on my resume is valuable. Having your ORM on my resume is not. And then there’s the “now you have two problems” dynamic. You not only have to write high-performing queries,…

ORMs are so incredibly finicky. I still remember using old Linq-to-SQL (not Entity Framework) and I had to write the linq query in the reverse order of what I expected or it created 3 nested subqueries instead of just joining the tables together. That was when I learned to instantly double check every ORM query I wrote.

Re: What ORMs have taught me: just learn SQL (2014)

#102

Post by frollogaston » Sat, Jul 04, 2026, 5:12 PM UTC

dmeijboom wrote: post #99

My point of view (after 18 years of programming): DO use frameworks (compile-time checked queries if you can) but skip ORMs that hide/obfuscate SQL completely as it will result in slow queries, extra round-trips, etc

I don't even use frameworks. I want my SQL and my regular code to be as close as possible to make it easy to reason about. Like SQL directly inlined with my JS/Py function. Don't need to mentally translate from some query builder to SQL or deal with some native "model" object it converts into. Have never suffered from a wrong-type bug.

Re: What ORMs have taught me: just learn SQL (2014)

#103

Post by Kinrany » Sat, Jul 04, 2026, 5:13 PM UTC

tengbretson wrote: post #100

I don't disagree with any of the major gripes people have with orms and I find SQL to be much cleaner in a lot of circumstances. That being said, if orms didn't force you to explicitly define your domain models about 60% of developers would simply never do it. And you would see differently structured, ad-hoc interfaces defined all over the code base completely entangled with whatever action they are trying to perform…

I'd rather take a mess of ad-hoc interfaces. Forcing people to do domain modeling does not go well.

Re: What ORMs have taught me: just learn SQL (2014)

#104

Post by frollogaston » Sat, Jul 04, 2026, 5:14 PM UTC

noisy_boy wrote: post #8

As someone who started their programming journey with SQL, it just feels so odd hearing about learning SQL being presented as an useful option. I get it, it just feels odd. SQL was considered table stakes in the financial IT world - if you said you didn't know SQL, people would look at you funny.

It should be table stakes for any SWEs working on backend, but it's not. The DB and the code directly interacting with it are way more important than anything you're going to write on top. I keep ending up in situations where I'm the only SWE in the room who really knows SQL, let alone proper schema design, and I have to speak up or else they're going to build an abomination.

Re: What ORMs have taught me: just learn SQL (2014)

#105

Post by 3eb7988a1663 » Sat, Jul 04, 2026, 5:15 PM UTC

flir wrote: post #6

add-sub-mul-div wrote: post #3

2014: people respond with indignance that they should have to learn SQL now that there's a shortcut 2026: people respond with indignance that they should have to learn anything now that there's a shortcut

I like SQL. I enjoy writing SQL. I find ORMs produce crap SQL. But the current shortcut du jour is pretty damn good at writing SQL.

I write SQL every day, but I cannot get onboard with liking the language. Yes, it is incredible that the language has had such staying power. No, it is not great that such a flawed design has persisted.

I enjoy this article[0] about some of the persistent warts which will seemingly never change.

[0]https://www.geldata.com/blog/we-can-do-better-than-sql

Re: What ORMs have taught me: just learn SQL (2014)

#106

Post by sandreas » Sat, Jul 04, 2026, 5:16 PM UTC

tengbretson wrote: post #100

I don't disagree with any of the major gripes people have with orms and I find SQL to be much cleaner in a lot of circumstances. That being said, if orms didn't force you to explicitly define your domain models about 60% of developers would simply never do it. And you would see differently structured, ad-hoc interfaces defined all over the code base completely entangled with whatever action they are trying to perform…

Additionally I think the migration management that most ORMs support are also a good thing. Defined and type-safe forward and backward strategies are helpful in most cases, especially if you'd like to support more than one DBMS.

I personally think that ORMs are good for management and simple CRUD cases, QueryBuilders are good for managing more complex queries while still being secure / type-safe and for everything else a thin database abstraction layer for native SQL queries with parameters / prepared statements is still required especially for performance use cases.

Re: What ORMs have taught me: just learn SQL (2014)

#107

Post by laszlokorte » Sat, Jul 04, 2026, 5:17 PM UTC

In my opinion Elixir Ecto is ORM done right:

1. the functional/immutable nature of Elixir makes read and writes much more explicit and there is no need to magically track deep mutations of nested objects to translate them back into UPDATE/INSERT queries

2. Elixirs support for lisp-like macros allows for an ergonomic embedded query languages that is syntax and schema checked, mirrors raw SQL really well and, frees you from string-oriented query building

3. the query builder DSL addresses one of the main weaknesses of SQL query statements not being composable

4. The automatic conversion between JOINed tables (on the DB side) and nested structs (on the Elixir side) is done on the right abstraction level to work reliable and and being explicit enough to generate predictable queries.

Re: What ORMs have taught me: just learn SQL (2014)

#108

Post by vindex10 » Sat, Jul 04, 2026, 5:19 PM UTC

It's a bit aside, but what i love about ORM frameworks is that they try to find the universal interface to multiple database backends. For basic CRUD it's nice: test on sqlite deploy wherever.

Re: What ORMs have taught me: just learn SQL (2014)

#109

Post by stephen » Sat, Jul 04, 2026, 5:22 PM UTC

hn_throwaway_99 wrote: post #48

stephen wrote: post #15

I'm admittedly an ORM apologist [1], but a few of his points articulated as "deal breakers" aren't that bad imo: - "the pernicious use of foreign keys [...] links between classes are [...] foreign keys" ==> that just sounds like schema normalization, which is usually a good thing? - "bending over backwards [...] to generate SQL that runs efficiently" ==> the huge majority of ORM-driven queries are "select * from tabl…

> "bending over backwards [...] to generate SQL that runs efficiently" ==> the huge majority of ORM-driven queries are "select * from table where id in ..."; for the queries that are more complicated than that, then yes use SQL! That's allowed! This is exactly why I hate ORMs. As I always put it "ORMs make the easy stuff slightly easier, and they make the harder stuff way harder". If you're just using an OEM for the…

Disclaimer I just edited this into my OP comment, but "generating boilerplate INSERTs" is not the main reason I use ORMs -- it's business rule enforcement.

I.e. regardless of how easy it is to write `INSERT authors (...) VALUES (...)`, with an appropriately cute/ergonomic query builder to bind the variables/POJOs ... where does your business logic actually go?

Whenever you insert an author, are you always enforcing the same validation logic? Whenever you update a book, are you always updating the derived fields that need updated?

Getting the business rules right is "the actual hard stuff" imo, and nothing I've seen a query builder help with; it's always left as an exercise to the reader to reinvent their "business logic wrapped around POJOs" adhoc in their codebase.

Re: What ORMs have taught me: just learn SQL (2014)

#110

Post by gorgonian » Sat, Jul 04, 2026, 5:23 PM UTC

meindnoch wrote: post #90

dadie wrote: post #18

Earlier quoted context omitted.

I think the bigger problem is that SQL is in almost every language a second-class citizen. And even calling it second-class can be seen as a stretch.

That's why it's called SQL aka String Query Language. The queries are just strings.

Are you being cheeky? The S stands for Structured.