[1a527dd5]

ORMs are one of those topics that get hotly debated for little reason IMO.

ORMs like almost everything else in SWE they are _tool_. It's not a law or a prescription. It's not mandatory.

ORMs are fine for 99% of cases. When it isn't fine use raw sql, no one is going to mock you, no one is going to jeer at you. Most times ORMs are fine, sometimes they are not.

[default-kramer]

I think the reason they get hotly debated is that people's personal experiences with them differ. Imagine that every time Alice has seen an ORM used it has been used responsibly, while every time Bob has seen an ORM used it has been used recklessly/sloppily. I'm more like Bob. Every project that I've seen use an ORM performs poorly, with select N+1s being the norm and not the exception.

[Ferret7446]

The problem with ORMs is that they're a very leaky abstraction. Database performance matters a lot for any non-trivial application, and in order to use an ORM performantly you need to understand both the underlying SQL+database but also all of the nuances of how the ORM maps to SQL.

So basically you end up with two situations:

1. You need to hire engineers with double the expertise (not just a SQL engineer, but a SQL+ORM engineer).

1a. You hire a SQL engineer who now has to learn Yet Another ORM.

2. You hire engineers who only know the ORM but not SQL, and your app ends up having shit performance.

Basically, ORMs are simply complicated SQL generating macro frameworks. They are way too leaky to provide a useful level of abstraction like most programming languages.

LLM coding tools may displace ORMs, because they can take away a lot of the tedium with integrating application SQL, which is what ORMs are supposed to do.

[procaryote]

Mixing ORMs and raw sql doesn't always work well with ORMs so you often end up in situations where the ORM made the easy parts easier and the hard parts harder.

[cies]

I disagree to a point that I wrote an article about it.

https://dev.to/cies/the-case-against-orms-5bh4

> Most times ORMs are fine, sometimes they are not.

When fine is defined as "improves dev't speed" I think they are not "fine" for any serious (say 100kLOC+ size) project.

> It's not a law or a prescription.

They come with a lot of webFWs, to the point that a lot of web software is built on top of them. These FWs (Django, Rails, Laravel, Symfony, Play, etc.) promote the use of ORMs.

[fatbird]

I worked on the pokemon.com website for several years. It has over 2 million LoC in python (~2.5 once you add in frontend JS). It's a Django site that uses Django's ORM; I can't recall ever seeing any raw SQL. As you might imagine, the site has high traffic and high performance requirements. We never found the ORM layer to be either a hindrance or a performance barrier.

[taffer]

Before the invention of SQL, people wrote software using VSAM files and navigational databases with extremely limited computing and memory resources and it worked.

That isn't the point, though. Some people, myself included, find that processing the data in a declarative language directly in the database makes your code simpler and less prone to bugs.

[grim_io]

How? Stored procedures?

I find that to be insane.

How do you version that code, and how do you reason with the business logic split all over the DB and code?

[taffer]

> How? Stored procedures?

Not neccesarily. jOOQ[1] and sqlc[2] are great options if you don't like stored procedures, but for a small app or a prototype, just having plain SQL strings in your app is fine.

My point isn't that the code has to be stored in the database, but rather that the processing happens in one place where your data is stored and your middle tier just gets the results. Pure, stateless data. This means you don't have to synchronise shared mutable state between your app and your DB server, cutting out all the headaches of ORMs, such as having to specify your data model in two separate places, n+1 queries, locking, lifecycle management, dirty tracking, eager loading, caching, and optimistic concurrency control. All of this adds to complexity and congnitive load.

SQL also provides a declarative approach to defining your business logic. You define the what, not the how. In addition to greater productivity, the programming model is much simpler because you aren't complecting control flow with data flow. With JSON support in Postgres, your query results don't have to be flat tables either. You can get your data in the exact shape you need.

> How do you version that code

You put it into your VCS. SQL is part of your code base, you can and should version control it just like any Python, Ruby or Java code. When using stored procedures, I recommend putting them in a separate schema, so that the schema can be dropped and recreated in a single transaction during deployment. See [3] for an example of stored procedures under version control.

> how do you reason with the business logic split all over the DB and code

You separate your concerns instead of mixing them. The core business logic is in SQL, with your middle tier doing the plumbing, orchestration of external services and presentation.

[1] https://www.jooq.org/

[2] https://sqlc.dev/

[3] https://github.com/sivers/store

[grim_io]

I don’t get this at all, and I tried to understand it.

I'm good at SQL. When necessary (maybe once a year), I can drop into pure SQL instead of Django ORM like it's nothing.

The thing is, I can't imagine why I would ever want to.

All these anti ORM comments read like they want to be as close to the DB as possible.

This is not what I want. I don't care about guaranteeing the most efficient query, because it is never the bottleneck, not even close.

I want to be as expressive as I can be in the business logic, and I don't feel like I am using pure SQL.

[lukaseder]

jOOQ is also a great option if you do like stored procedures

[cies]

I cannot imagine a 2MLOC codebase with rdbms persistence that does not need custom SQL. I believe you, but I also think that's a special case.

[materielle]

My problems with ORMs is that they are a solution in search of a problem most of the time.

We already have an abstraction for interfacing with the DBMS. It’s called SQL, and it works perfectly fine.

[bakugo]

> We already have an abstraction for interfacing with the DBMS. It’s called SQL, and it works perfectly fine.

ORMs are not an abstraction to interface with the DBMS. They are an abstraction to map the data in your database to objects in your code and vice versa. It's literally in the name.

Feels like a lot of anti-ORM sentiment originates from people who literally don't know what the acronym means.

[lelanthran]

> They are an abstraction to map the data in your database to objects in your code and vice versa.

Maybe that's part of the problem - you're trying to map tabular data in your database to hierarchical data in your programming language.

Of course there's going to be all kinds of pain when pounding square pegs into round holes. Getting a better hammer (i.e. a better ORM) isn't necessarily going to help.

[bakugo]

Okay, so what's the round peg that goes in the round hole, here? Forgetting about objects and just passing around dicts or whatever with no type information?

[lelanthran]

> Forgetting about objects and just passing around dicts or whatever with no type information?

Why would you need to drop the type information when you stop using hierarchical structures for your data?

[sillywabbit]

You're working with bits. It's turtles all the way down.

[gitaarik]

The way it integrates into Django is more than just an abstraction to SQL. It's also an abstraction to your table schema, mapped to your model. In short, it's the Pythonic way of fetching data from your models in Django.

It allows for functional programming, as in building queries upon other queries. And predefined filters, easily combining queries, etc. And much more.

Of course you don't need all of that. But in a big project, where you might query some particular tables a lot of the times, and there are common joins you make between tables, then sometimes it is nice to have predefined models and columns and relations, so you need less verbosity when building the queries.

You do of course need to learn a new tool to build queries, but it does pay off in some cases.

[kdazzle]

Mostly, I think, the problem is SQL injection, and raw SQL is a great place for people to forget to escape their strings.

[jaggirs]

ORM's are not the only solution to SQL injection, pyscopg for example handles string escaping etc for you.

[kdazzle]

Yeah, if you remember to use it properly. SQL injection was pretty rampant before ORMs and web frameworks started being used everywhere.

ORMs let anyone make CRUD apps without needing to worry about that sort of thing. Also helps prevent issues from slipping through on larger teams with more junior developers. Or, frankly, even “senior” developers that don’t really understand web security.