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

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

#311

Post by nodamage » Sun, Jul 05, 2026, 5:57 PM UTC

jillesvangurp wrote: post #288

dpedu wrote: post #272

I'm totally on board with the idea that ORMs create a variety of inefficiencies, pain points, and make it really easy to create bad queries or querying strategies. But I use them anyways because the convenience of mapping a row to a code object makes writing programs feel fast and simple. And if you know how ORMs can cause problems and how to watch out for them, you can still get a lot of mileage out of them. That be…

> the convenience of mapping a row to a code object makes writing programs feel fast and simple. Even when you had to do this manually, it was a very minor effort. A one time thing. These days of course any half decent LLM will produce this code without much fanfare. The argument just melts away. Otherwise, ORMs just layer abstractions on abstractions. You end up with these weird half implied joins resulting in absol…

> Even when you had to do this manually, it was a very minor effort. A one time thing.

Maybe if you’re fetching data from a single table… once you start joining across multiple tables and need deduplicate your result rows it gets pretty annoying to do it by hand though.

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

#312

Post by Kon5ole » Sun, Jul 05, 2026, 6:14 PM UTC

mattmanser wrote: post #262

Kon5ole wrote: post #240

Earlier quoted context omitted.

>Why is your database so different from your domain? Usually it's due to one of these: - The domain deals with a lot of things that are not in the database. - The domain is one of many and deals with just a fraction of what is in the database. - The domain deals with things stored in several databases. - The database was designed in the 90s and the domain is new. - It's not my database so I can't change it. (Even for…

It's not that your domain is different, it sounds more like you don't know how to use ORMs. ORMs don't have to manage migrations, they don't have to even write into the database. When dealing with a bad database design, it can be a legitimate tactic to use ORMs in read-only mode and have writes still as hand-rolled SQL. You can do database-first ORMs, as well as code-first, where the database design is king, not the…

>It's not that your domain is different

You have mixed the posts you are replying to - the domain being different from the database is stipulated here.

I was giving examples of how this typically happens, and the reasons are entirely independent of whether or not an ORM is being used.

I am fully aware that you can handle any mess using an ORM as well, which is why I was surprised at the original claim that ORM's force proper domain models. I haven't observed that so I was genuinely curious.

Separately from that I have to say your suggestions of things to do to force an ORM into the situation are bad ideas. The complexity of custom serialization, various mapping hooks or attributes to bless individual properties will lead to pain and misery down the line.

Just accept the extra layer of DTO's. They're a detour over pure SQL but are at least easy to maintain and hold no surprises. They say there's a special place in hell for people who write SQL triggers and I think people who override ORM serializers are welcome there. ;-)

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

#313

Post by hn_throwaway_99 » Sun, Jul 05, 2026, 6:15 PM UTC

xigoi wrote: post #216

hn_throwaway_99 wrote: post #48

Earlier quoted context omitted.

> "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…

> If you're just using an OEM for the "select * from table where ID in ...", then you're saving practically nothing by using an ORM You’re saving hundreds of lines of repetitive boilerplate code. Do you enjoy writing something like users = [ User(name=name, color=color) for name, color in db.query("SELECT name, color FROM user") ] over and over?

The number of comments implying that ORMs are required for basic software engineering concepts like proper encapsulation and DRY is baffling.

But this gets to the heart of what I was saying. I'll grant you that ORMs save a little bit of boiler plate up front (but not much - ORMs have plenty of their own boiler plate, just instead of a universally understood language like SQL they have it in their own custom config JSON/yaml/XML), but that is where I spend a teeny fraction of my time coding. Writing "boilerplate" SQL for a decently large project (say 50-100 object types) takes me maybe an extra day in coding time. I have wasted multiples of that time trying to track down a single weird ORM bug, or poorly performing query. Plus, spending that time up front to write my queries is always the least stressful time of the project. What is most stressful is when my site is finally getting a big traffic push, but then something causes the DB to crater and the leaky abstraction of the ORM makes it ten times harder to debug.

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

#314

Post by Mikhail_Edoshin » Sun, Jul 05, 2026, 6:43 PM UTC

jhgb wrote: post #252

Mikhail_Edoshin wrote: post #209

Earlier quoted context omitted.

It solves a hard problem. For example, it completely insulates the sender from the fact that his transaction is just one among many others.

No, database servers solve that problem. That the unnecessarily COBOL-like SQL ended up being the primary interface to them is simply an unfortunate accident of history.

There have to be some limitations on the language for this to work. For example, there must be no way to specify a neverending loop or to lock something and forget to unlock, an so on.

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

#315

Post by Kon5ole » Sun, Jul 05, 2026, 6:43 PM UTC

Izkata wrote: post #310

webstrand wrote: post #273

Earlier quoted context omitted.

That doesn't sound at all like any ORM I've ever used. I've struggled in the past because The ones I've used are actively hostile to laying out data in the database in a way not proscribed by the ORMs philosophy. Heck of the ORMs I've used, one didn't support parameterized joins and the other didn't support joins at all. --- It's not usually a DB guy gatekeeping, it's that multiple apps use the same database so layou…

Except for the "multiple ORMs" part which is a level above it, it applies to the only one I've used extensively: Django for python. It has standard defaults, but just about everything overridable, and because models are python objects you can add methods or properties for extra data. There's even ways to define your own field types (the "serialization/de-serialization of individual properties"), which a decade ago pe…

>and Django was like this 15 years ago when I first started using it. The core design hasn't changed, it just sounds like most other ORMs don't really know what they're doing.

Django is an opinionated web framework that uses an ORM, not just an ORM.

Django can by all means be a great way to make a web site (I have little experience with it) but if you have a db that is accessed by various systems written in Java, dotnet, erlang or whatever else I suspect the smooth sailing of Django can run into headwinds quickly and the python plumbing you have to deal with then quickly becomes an issue in itself.

But I admit it's just a guess.

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

#316

Post by crispyambulance » Sun, Jul 05, 2026, 7:11 PM UTC

sgarland wrote: post #186

crispyambulance wrote: post #134

Earlier quoted context omitted.

> You can learn something like ~90% of useful SQL in an afternoon. Oh, HELL NO! It's an ugly little language that one has to come back to and re-learn over and over at different levels of sophistication. Nothing wrong with that, but to suggest it's trivial is a gross mischaracterization.

I’m a DBRE, and also happen to like SQL. With that as a disclaimer, I really do not think it’s a difficult language to learn. Learning the intricacies of your RDBMS’ behavior for various functions (like MySQL’s ORDER BY and GROUP BY optimizations) is complicated, but that’s what docs are for.

   > I really do not think it’s a difficult language to learn.

Neither do I, but there's huge distances between "spend-an-afternoon-intro-on-it" and "learn-it-well-enough-for-occasional-work" and "learn-it-enough-to-build-serious-databases".

Of course, everyone in HN is "advanced" so what do I know!

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

#317

Post by ezst » Sun, Jul 05, 2026, 7:19 PM UTC

to11mtm wrote: post #301

cultofmetatron wrote: post #292

Earlier quoted context omitted.

> Yes, there is a middle ground. Elixir's Ecto does this well. Ecto is by far the closest thing to a perfect pattern for abstracting over sql that I've ever seen. I WISH other languages would create similar libraries. Its the biggest thing keeping me coming back to elixir for any kind of database project. it just makes sql so ergonomic.

I mean FWIW Scala has Slick (but then you're dealing with the rest of Scala ecosystem...) and there's Linq2Db on .NET side. Having dealt with all 3 on some level (Slick the least) I would say they are fairly similar in intent (i.e. differences are primarily due to language idioms.)

I'm not sure Slick is still maintained. Recently I depended on https://github.com/com-lihaoyi/scalasql#simpletable-variant-... for small CRUD stuff and liked it quite a bit. These days there's a whole boulevard through the Scala ecosystem that doesn't involve typelevel pedantry and obscure DSLs just for the love of hieroglyphics.

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

#318

Post by Izkata » Sun, Jul 05, 2026, 7:20 PM UTC

Kon5ole wrote: post #315

Izkata wrote: post #310

Earlier quoted context omitted.

Except for the "multiple ORMs" part which is a level above it, it applies to the only one I've used extensively: Django for python. It has standard defaults, but just about everything overridable, and because models are python objects you can add methods or properties for extra data. There's even ways to define your own field types (the "serialization/de-serialization of individual properties"), which a decade ago pe…

>and Django was like this 15 years ago when I first started using it. The core design hasn't changed, it just sounds like most other ORMs don't really know what they're doing. Django is an opinionated web framework that uses an ORM, not just an ORM. Django can by all means be a great way to make a web site (I have little experience with it) but if you have a db that is accessed by various systems written in Java, dot…

> but if you have a db that is accessed by various systems written in Java, dotnet, erlang or whatever else I suspect the smooth sailing of Django can run into headwinds quickly

Only if those systems are constantly adding/removing tables and columns. And adding isn't a problem, Django just ignores what's not specified in the models.

Django does have default table and column names based on the models that it prefers, but all of it is overridable in officially-supported ways. We're using it with mysql databases originally made for VB6 and C++ with inconsistent naming schemes that aren't even close to Django's defaults, that nowadays are also accessed by perl, php, and python. Most of our python uses are daemons that only use the models and none of the rest of the web framework - the models are defined in a common library they all use.

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

#319

Post by ElectricalUnion » Sun, Jul 05, 2026, 7:47 PM UTC

dsego wrote: post #305

simondotau wrote: post #239

Earlier quoted context omitted.

Query builders are a doddle to write, extremely trivial to debug, and generally far easier overall than having to shoehorn data into a structure that your ORM likes. The problem is not that ORMs fail to expose every feature of a particular SQL database. The problem is that they encourage you to model your data in a way that is convenient for the ORM, rather than in a way that is correct for the domain. Any sufficient…

It seems like you are throwing away the baby with the bathwater. I don't think providing 90% of the structure you need is a failed abstraction. And it just doesn't follow that it is pushing you towards sub-optimal structures, not sure where this conclusion comes from. All ORMs I've seen have ways to describe relations between models, even polymorphic types, aggregates, eager loading (to avoid N+1) etc.

> I don't think providing 90% of the structure you need is a failed abstraction.

It is, when the "10%" is the actual hot queries that your system will use the most?

Code right now "is so cheap". You can provide your favourite LLM with your database schema, and some domain comments, and ask it a query to fetch/update data, and it will generate somewhat sane queries for you. You can then inspect those queries yourself, send them to another LLM or human to review and, when they look OK, ship it.

And when it comes time to debug it, you have, you know, an actual query, not some pseudo-query in a custom DSL. No need to implement runtime telemetry just to try to figure out if the ORM actually made the query you thought it was supposed to do.

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

#320

Post by bluefirebrand » Sun, Jul 05, 2026, 9:22 PM UTC

crispyambulance wrote: post #316

sgarland wrote: post #186

Earlier quoted context omitted.

I’m a DBRE, and also happen to like SQL. With that as a disclaimer, I really do not think it’s a difficult language to learn. Learning the intricacies of your RDBMS’ behavior for various functions (like MySQL’s ORDER BY and GROUP BY optimizations) is complicated, but that’s what docs are for.

> I really do not think it’s a difficult language to learn. Neither do I, but there's huge distances between "spend-an-afternoon-intro-on-it" and "learn-it-well-enough-for-occasional-work" and "learn-it-enough-to-build-serious-databases". Of course, everyone in HN is "advanced" so what do I know!

> learn-it-enough-to-build-serious-databases

This is more about infrastructure than SQL though. You don't need to know any fancy SQL to do streaming replication or whatever, for instance.

You're correct that being good at Managing Data is a complex domain with a lot of gnarly bits, but I was talking about Writing SQL being fairly easy