5 ms·

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 prescri

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.

procaryote 1y ago
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 1y ago
I disagree to a point that I wrote an article about it. https://dev.to/cies/the-case-against-orms-5bh4 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 1y ago
  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 1y ago
    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 1y ago
      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 1y ago
        > 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/ https://www.jooq.org/ [2] https://sqlc.dev/ https://sqlc.dev/ [3] https://github.com/sivers/store https://github.com/sivers/store
        grim_io 1y ago
        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.
  - cies 1y ago
    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 1y ago
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 1y ago
  > 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 1y ago
    > 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 1y ago
      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 1y ago
        > 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 1y ago
      You're working with bits. It's turtles all the way down.
default-kramer 1y ago
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 1y ago
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 1y ago

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 1y ago

I disagree to a point that I wrote an article about it. https://dev.to/cies/the-case-against-orms-5bh4 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 1y ago
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 1y ago
  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 1y ago
    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 1y ago
      > 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/ https://www.jooq.org/ [2] https://sqlc.dev/ https://sqlc.dev/ [3] https://github.com/sivers/store https://github.com/sivers/store
      - grim_io 1y ago
        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.
- cies 1y ago
  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 1y ago

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 1y ago
> 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 1y ago
  > 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 1y ago
    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 1y ago
      > 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 1y ago
    You're working with bits. It's turtles all the way down.

default-kramer 1y ago

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 1y ago

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.