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

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

#191

Post by jiggawatts » Sun, Jul 05, 2026, 4:38 AM UTC

Something I'd like to see is for someone to finally come to the realisation that the right thing to do is to make the front-end web templating language truly polyglot and support SQL natively, without an ORM wrapper.

For example, the ASP.NET Razor syntax allows HTML and C# code to be interspersed surprisingly freely:

    
    @foreach (var user in Model.Users)
    {
      @user.Name
    }

Just picture the same kind of thing, but with SQL expressions freely interspersed with the programming language.

Just like how Cargo, NuGet, NPM, etc... can import packages and/or how you can cross-reference projects in build systems, web apps should be able to reference a database schema project directly, importing the SQL definitions without any explicit "mapping". If the SQL changes, the type changes, and the build system picks that up automatically without any additional manual steps.

.NET with EF Core is almost there, and I've seen some half-hearted attempts in various languages over the years, but it's like the industry has an allergy to the concept.

Ur/Web is probably the closest to the idealised concept, and I think that's what I read years ago that put the dream in my mind: https://dl.acm.org/cms/attachment/feb131ab-37e1-4638-be17-ab...

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

#192

Post by theptip » Sun, Jul 05, 2026, 4:52 AM UTC

ElectricalUnion wrote: post #150

sandreas wrote: post #106

Earlier quoted context omitted.

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

> ORMs are good for management and simple CRUD cases I for one think that "simple CRUD cases" is bullshit, those applications don't exist. In practice, System-of-Records systems are rare. (and should be, their value are inversely proportional of how many of those you have in your overall system). Because if it was "just simple CRUD", one would use the database directly? Databases are already capable of handling CRUD…

No. If you have a simple line-of-business app, writing Django/Rails models is FAR easier than the equivalent SQL.

Even if you think that maintaining your domain model is easier in SQL (it’s not, for most full-stack engineers), the extra capabilities you get from an ActiveRecord framework such as full-stack admin pages, free migrations, etc. win overall.

I can believe that the gap is closing with the “api for your Postgres” frameworks but really, try reaching your frontend developers sql and see if they have a better time than learning Django/Rails.

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

#193

Post by ozgrakkurt » Sun, Jul 05, 2026, 5:00 AM 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…

> if orms didn't force you to explicitly define your domain models about 60% of developers would simply never do it

This was never the experience I had. If anything, people tend to plan too much.

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

#194

Post by bytefish » Sun, Jul 05, 2026, 5:17 AM UTC

What usually happens in my experience is, that a home-grown Data Access Layer usually turns into a bad "ORM light", because materializing results is repetitive and tiring work. You want to abstract it away.

As a .NET developer I think EF Core has made the right call here, by allowing you to write SQL where it's needed and still use its infrastructure for all the tedious work of materializing your results.

Admittedly in 2014, the time the article was written at, I've also felt using OR-Mapper is a dead-end. But in 2026 the world isn't black and white.

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

#195

Post by yeswecatan » Sun, Jul 05, 2026, 5:30 AM UTC

sdevonoes wrote: post #167

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 understand you mean “data” model instead? Perhaps for simple cruds, there’s no much point in differentiating between the data model and the domain model. For more complex scenarios, having orm concerns leak into the domain model is not nice

This is one of the major drawbacks to ORMs imo (though it’s not necessarily the ORMs fault). People think domain and data models are the same but they most definitely are not.

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

#196

Post by therealdrag0 » Sun, Jul 05, 2026, 5:58 AM UTC

valzam wrote: post #7

The big problem is that raw SQL has pretty bad type inference and linting support in most editors. A query builder can still give you a lot of type safety benefits.

Use testcontainers and make sure you have an integration test for every query..

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

#197

Post by therealdrag0 » Sun, Jul 05, 2026, 6:02 AM UTC

bluefirebrand wrote: post #149

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.

> different levels of sophistication Most of those are not necessary for 90% of use cases I'm not taking the piss either All most people really need to know is table CRUD, row CRUD, and a bit about indices. For anything more advanced you'll need a DBA, but IMO you unless you are scaling like crazy you will not need much more than that for SQL knowledge. It's really, really not that complex for most use cases

You should also learn joins and ordering/pagination. But that can be on day 2 :)

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

#198

Post by drdexebtjl » Sun, Jul 05, 2026, 6:31 AM UTC

bytefish wrote: post #194

What usually happens in my experience is, that a home-grown Data Access Layer usually turns into a bad "ORM light", because materializing results is repetitive and tiring work. You want to abstract it away. As a .NET developer I think EF Core has made the right call here, by allowing you to write SQL where it's needed and still use its infrastructure for all the tedious work of materializing your results. Admittedly…

I’ve had so many frustrations with EF Core.

I always inevitably want to model something in the domain in a way that is not be supported by EF. So I have to maintain EF DTOs and basically give up on the change tracker.

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

#199

Post by miohtama » Sun, Jul 05, 2026, 6:38 AM 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…

SQL is pretty shitty language to write modular, reusable and easy to read code.

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

#200

Post by willtemperley » Sun, Jul 05, 2026, 6:48 AM UTC

ElectricalUnion wrote: post #150

sandreas wrote: post #106

Earlier quoted context omitted.

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

> ORMs are good for management and simple CRUD cases I for one think that "simple CRUD cases" is bullshit, those applications don't exist. In practice, System-of-Records systems are rare. (and should be, their value are inversely proportional of how many of those you have in your overall system). Because if it was "just simple CRUD", one would use the database directly? Databases are already capable of handling CRUD…

Developing apps in SwiftUI it’s extremely useful to have SwiftData, an ORM that can act like a system of records. For my own use case this is basically metadata for large scale datasets in Parquet or similar.

That said it’s still my most frequent cause of crashes, however I think mostly it’s just because this is simply a hard problem that SQLite just isn’t cut out for (although it did take Apple until macOS 27 to supply a codable decorator grrr).

Ideally databases could evolve to fit OR mapping more closely, which incidentally is what Arrow and Parquet have done to an extent.