5 ms·

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'

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. ORMs being a forcing function for domain modeling is enough benefit for me that it outweighs all of their obvious limitations.

Kinrany 2mo ago
I'd rather take a mess of ad-hoc interfaces. Forcing people to do domain modeling does not go well.
- simondotau 2mo ago
  Pretending that domain modelling is optional does not go well.
  - Kinrany 2mo ago
    Sure, but it's better to do no domain modelling than to pretend doing it.
    - simondotau 2mo ago
      “Doing no domain modelling” is not really an option. It just means the domain model emerges accidentally from ad-hoc interfaces, conditionals, database fields, validation rules, and UI assumptions. Asking an LLM to help with domain modelling isn't ideal, but it's strictly superior to having your model designed by accident, informed primarily by the initial rough draft of your application code.
- deleted 2mo ago
  [deleted]
sandreas 2mo ago
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.
- ElectricalUnion 2mo ago
  > 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 and much more with way less implementation bugs. Even assuming your application "is a system-of-record", how is it giving any more value that directly using a ready-made solution like Oracle REST Data Services, or PostgREST?
  - sandreas 2mo ago
    If the ORM is capable of validation or integrates with such a component, i personally think that it integrates well for these parts of an APP, where simple datamanagement is required... E.g. adding, editing and deleting DB records, that need forms and validation.
  - Charon77 2mo ago
    Agreed. Simple CRUD is something that only shows up in the beginning of the project, everyone was told to use ORM for that purpose, business grow, and you had awkward requirements that require complex ORM features which might exist but requires deep dive into ORM library's corner case, or just straight not possible and makes you bang your head wishing you'd write SQL instead where it would have been obvious what to write. The only good thing about ORM is the type safety, but I find rust's sqlx or java's jooq to be hitting the sweet spot.
ibejoeb 2mo ago
Wouldn't you consider defining the schema doing the domain modeling? I think ORMs do too much. I want to control the querying, or, more precisely, I want to control the SQL that goes to the planner. The good ones largely do allow for this, but I can't think of one that has innate support for vendor-specific features. What I do appreciate is that they handle the boilerplate like managing connections, preparing statements, setting parameter values, and mapping database types back to client types.
- zbentley 2mo ago
  > Wouldn't you consider defining the schema doing the domain modeling? No, because if the schema is the only reference for data models, developers on any sufficiently large team will come up with extremely widely varied queries to access equivalent information. Those are more likely to be incorrect (someone with domain expertise on one set of tables might miss that authoritative data needs to be joined/queried from elsewhere), harder to update when schemas change (more client code changes to alter and test), and more likely to miss performant techniques to query data. Those can all be addressed with disciplined use of views or common utility SQL snippets or functions, but ORMs also get you to that point without requiring as much ongoing discipline, care, and feeding.
  - ibejoeb 2mo ago
    > Those can all be addressed with disciplined use of views... Totally agree. Views as a data API is the best way to take advantage of the facilities that the database itself offers and guarantees enforces consistency across disparate clients.
  - ElectricalUnion 2mo ago
    > developers on any sufficiently large team will come up with extremely widely varied queries to access equivalent information. Ah yes, the famous database integration anti-pattern. > but ORMs also get you to that point without requiring as much ongoing discipline, care, and feeding. [citation needed] The fact that you have being practising "database integration" won't suddenly disappear just because you used a ORM. In fact I expect even worse database integration from your average ORM user, as people that uses ORM blindly often don't care (to their own detriment) about "silly issues" like data provenance or persistence mechanical sympathy. At some point I expect the DBAs of such database integration nightmares will have to start handling stuff like column-level security and row-level security to prevent naive users from shooting themselves in the foot.
frevib 2mo ago
You shouldn’t use ORM entities as domain models. The domain should not depend on anything from the integration layer (db entities, REST request/ response, etc). Ideally models are generated from SQL schemas, which you map to domain models.
sdevonoes 2mo ago
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
- nesarkvechnep 2mo ago
  This is exactly what happens in a typical Elixir project even though Ecto is a query builder and not an ORM. People define their domain entities as database tables. The result is, from my latest project, you have user and organisation memberships which are a list of membership records. This is carried throughout the application while it should be a hash map of organisation IDs and membership data, so you can check if a user is a member of an organisation in constant time. Of course keeping ourselves coupled to the database representation is easier than defining a view, for example, which takes care of presenting the data in a useful form for the application.
  - vips7L 2mo ago
    That’s a problem with ecto and not ORMs. A good ORM will be able to do that hashmap mapping.
    - nesarkvechnep 2mo ago
      It’s a problem of philosophy, not tooling.
- yeswecatan 2mo ago
  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.
Kon5ole 2mo ago
>ORMs being a forcing function for domain modeling is enough benefit for me that it outweighs all of their obvious limitations. That was a surprising take! I know only a few ORM's but it seems they end up just adding another layer of DTO objects that are entirely separate from the domain classes anyway. So best case the ORM is just a detour for a good domain model. Worst case it creates a weird database-contaminated domain model that's hellish to maintain. So I would't say ORMs force domain modeling, or even help. Are you perhaps thinking of a particular stack where the ORM is just one part of it?
- Exoristos 2mo ago
  Why is your database so different from your domain?
  - wuiheerfoj 2mo ago
    I doubt domain logic would ever be in 2NF. My domain logic certainly doesn’t have pivot tables of IDs for join lookup
  - Ntrails 2mo ago
    Most commonly ime the application domain may only be some small fraction of the database which is designed/optimised for a much broader dataset.
  - Kon5ole 2mo ago
    >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 greenfield systems I don't think it's generally desirable that the database matches the domain model.)
    - mattmanser 2mo ago
      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 POCO. > The domain deals with a lot of things that are not in the database. You can have non-serialized properties. You can even can over-ride serialization/de-serialization of individual properties > The domain is one of many and deals with just a fraction of what is in the database You can use different ORMs for different parts of your domain, you could even wrap multiple ORMs in a wrapper repo pattern if you want > The domain deals with things stored in several databases As above. > The database was designed in the 90s and the domain is new Tons of solutions for this, one easy one is using SQL Views, just ask Claude. The weird thing here is that I've now dealt with this IRL like 5 times and came to the opposite conclusion of you. I found wrapping a bad DB design with an ORM a great first step in fixing it, as the ORM effectively acts as an easy strangler pattern. > It's not my database so I can't change it You can still use ORMs, ORMs don't have to manage migrations. Though I feel sorry for you working somewhere you still have a DB guy gatekeeping the database design in 2026. The point is, every one of your objections are pretty trivially solvable with many mature ORMs, because everyone else had the same problems two decades ago and instead of throwing up their hands and hand-rolling their SQL, the ORM tooling was improved.
j45 2mo ago
Too often, the avoidance of learning SQL creates more work than learning SQL. One example is starting with NOSQL and proceeding to learn how to make it into a relational database.
ozgrakkurt 2mo ago
> 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.
miohtama 2mo ago
SQL is pretty shitty language to write modular, reusable and easy to read code.
- Mikhail_Edoshin 2mo ago
  It solves a hard problem. For example, it completely insulates the sender from the fact that his transaction is just one among many others.
  - jhgb 2mo ago
    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.
    - Mikhail_Edoshin 2mo ago
      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.
- Foobar8568 2mo ago
  It's easy to read SQL code as long as the person writing the query doesn't resort to "hack" the planner. Now to make that reusable....That's another beast and most often will defeat the purpose of writing pure SQL in the first place, let's put a OR there, let's call several queries, let's screw the data model.
- Cthulhu_ 2mo ago
  ORMs often end up defining their own domain-specific language which is neither SQL nor the language itself, so they don't really solve that problem except in the simplest cases.
  - mexicocitinluez 2mo ago
    With the big exception of Entity Framework which relies on LINQ.
grumple 2mo ago
I think you hit the nail on the head. I’m thinking about what Rails would look like without activemodel and activerecord. Or even just without activerecord, where we had to write the same sql every time we wrote a model but introduce the opportunity for a dev to screw it up. Imagine starting on a legacy code base and all the models had subtle differences in how they query the db. They don’t have the established conventions around _id fields, polymorphism, the nice bits around joins, and instead you have to discover bugs where you did a join but the two models each have a field called “description”…

Kinrany 2mo ago

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

simondotau 2mo ago
Pretending that domain modelling is optional does not go well.
- Kinrany 2mo ago
  Sure, but it's better to do no domain modelling than to pretend doing it.
  - simondotau 2mo ago
    “Doing no domain modelling” is not really an option. It just means the domain model emerges accidentally from ad-hoc interfaces, conditionals, database fields, validation rules, and UI assumptions. Asking an LLM to help with domain modelling isn't ideal, but it's strictly superior to having your model designed by accident, informed primarily by the initial rough draft of your application code.
deleted 2mo ago
[deleted]

sandreas 2mo ago

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.

ElectricalUnion 2mo ago
> 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 and much more with way less implementation bugs. Even assuming your application "is a system-of-record", how is it giving any more value that directly using a ready-made solution like Oracle REST Data Services, or PostgREST?
- sandreas 2mo ago
  If the ORM is capable of validation or integrates with such a component, i personally think that it integrates well for these parts of an APP, where simple datamanagement is required... E.g. adding, editing and deleting DB records, that need forms and validation.
- Charon77 2mo ago
  Agreed. Simple CRUD is something that only shows up in the beginning of the project, everyone was told to use ORM for that purpose, business grow, and you had awkward requirements that require complex ORM features which might exist but requires deep dive into ORM library's corner case, or just straight not possible and makes you bang your head wishing you'd write SQL instead where it would have been obvious what to write. The only good thing about ORM is the type safety, but I find rust's sqlx or java's jooq to be hitting the sweet spot.

ibejoeb 2mo ago

Wouldn't you consider defining the schema doing the domain modeling? I think ORMs do too much. I want to control the querying, or, more precisely, I want to control the SQL that goes to the planner. The good ones largely do allow for this, but I can't think of one that has innate support for vendor-specific features. What I do appreciate is that they handle the boilerplate like managing connections, preparing statements, setting parameter values, and mapping database types back to client types.

zbentley 2mo ago
> Wouldn't you consider defining the schema doing the domain modeling? No, because if the schema is the only reference for data models, developers on any sufficiently large team will come up with extremely widely varied queries to access equivalent information. Those are more likely to be incorrect (someone with domain expertise on one set of tables might miss that authoritative data needs to be joined/queried from elsewhere), harder to update when schemas change (more client code changes to alter and test), and more likely to miss performant techniques to query data. Those can all be addressed with disciplined use of views or common utility SQL snippets or functions, but ORMs also get you to that point without requiring as much ongoing discipline, care, and feeding.
- ibejoeb 2mo ago
  > Those can all be addressed with disciplined use of views... Totally agree. Views as a data API is the best way to take advantage of the facilities that the database itself offers and guarantees enforces consistency across disparate clients.
- ElectricalUnion 2mo ago
  > developers on any sufficiently large team will come up with extremely widely varied queries to access equivalent information. Ah yes, the famous database integration anti-pattern. > but ORMs also get you to that point without requiring as much ongoing discipline, care, and feeding. [citation needed] The fact that you have being practising "database integration" won't suddenly disappear just because you used a ORM. In fact I expect even worse database integration from your average ORM user, as people that uses ORM blindly often don't care (to their own detriment) about "silly issues" like data provenance or persistence mechanical sympathy. At some point I expect the DBAs of such database integration nightmares will have to start handling stuff like column-level security and row-level security to prevent naive users from shooting themselves in the foot.

frevib 2mo ago

You shouldn’t use ORM entities as domain models. The domain should not depend on anything from the integration layer (db entities, REST request/ response, etc). Ideally models are generated from SQL schemas, which you map to domain models.

sdevonoes 2mo ago

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

nesarkvechnep 2mo ago
This is exactly what happens in a typical Elixir project even though Ecto is a query builder and not an ORM. People define their domain entities as database tables. The result is, from my latest project, you have user and organisation memberships which are a list of membership records. This is carried throughout the application while it should be a hash map of organisation IDs and membership data, so you can check if a user is a member of an organisation in constant time. Of course keeping ourselves coupled to the database representation is easier than defining a view, for example, which takes care of presenting the data in a useful form for the application.
- vips7L 2mo ago
  That’s a problem with ecto and not ORMs. A good ORM will be able to do that hashmap mapping.
  - nesarkvechnep 2mo ago
    It’s a problem of philosophy, not tooling.
yeswecatan 2mo ago
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.

Kon5ole 2mo ago

>ORMs being a forcing function for domain modeling is enough benefit for me that it outweighs all of their obvious limitations. That was a surprising take! I know only a few ORM's but it seems they end up just adding another layer of DTO objects that are entirely separate from the domain classes anyway. So best case the ORM is just a detour for a good domain model. Worst case it creates a weird database-contaminated domain model that's hellish to maintain. So I would't say ORMs force domain modeling, or even help. Are you perhaps thinking of a particular stack where the ORM is just one part of it?

Exoristos 2mo ago
Why is your database so different from your domain?
- wuiheerfoj 2mo ago
  I doubt domain logic would ever be in 2NF. My domain logic certainly doesn’t have pivot tables of IDs for join lookup
- Ntrails 2mo ago
  Most commonly ime the application domain may only be some small fraction of the database which is designed/optimised for a much broader dataset.
- Kon5ole 2mo ago
  >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 greenfield systems I don't think it's generally desirable that the database matches the domain model.)
  - mattmanser 2mo ago
    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 POCO. > The domain deals with a lot of things that are not in the database. You can have non-serialized properties. You can even can over-ride serialization/de-serialization of individual properties > The domain is one of many and deals with just a fraction of what is in the database You can use different ORMs for different parts of your domain, you could even wrap multiple ORMs in a wrapper repo pattern if you want > The domain deals with things stored in several databases As above. > The database was designed in the 90s and the domain is new Tons of solutions for this, one easy one is using SQL Views, just ask Claude. The weird thing here is that I've now dealt with this IRL like 5 times and came to the opposite conclusion of you. I found wrapping a bad DB design with an ORM a great first step in fixing it, as the ORM effectively acts as an easy strangler pattern. > It's not my database so I can't change it You can still use ORMs, ORMs don't have to manage migrations. Though I feel sorry for you working somewhere you still have a DB guy gatekeeping the database design in 2026. The point is, every one of your objections are pretty trivially solvable with many mature ORMs, because everyone else had the same problems two decades ago and instead of throwing up their hands and hand-rolling their SQL, the ORM tooling was improved.

j45 2mo ago

Too often, the avoidance of learning SQL creates more work than learning SQL. One example is starting with NOSQL and proceeding to learn how to make it into a relational database.

ozgrakkurt 2mo ago

> 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.

miohtama 2mo ago

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

Mikhail_Edoshin 2mo ago
It solves a hard problem. For example, it completely insulates the sender from the fact that his transaction is just one among many others.
- jhgb 2mo ago
  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.
  - Mikhail_Edoshin 2mo ago
    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.
Foobar8568 2mo ago
It's easy to read SQL code as long as the person writing the query doesn't resort to "hack" the planner. Now to make that reusable....That's another beast and most often will defeat the purpose of writing pure SQL in the first place, let's put a OR there, let's call several queries, let's screw the data model.
Cthulhu_ 2mo ago
ORMs often end up defining their own domain-specific language which is neither SQL nor the language itself, so they don't really solve that problem except in the simplest cases.
- mexicocitinluez 2mo ago
  With the big exception of Entity Framework which relies on LINQ.

grumple 2mo ago

I think you hit the nail on the head. I’m thinking about what Rails would look like without activemodel and activerecord. Or even just without activerecord, where we had to write the same sql every time we wrote a model but introduce the opportunity for a dev to screw it up. Imagine starting on a legacy code base and all the models had subtle differences in how they query the db. They don’t have the established conventions around _id fields, polymorphism, the nice bits around joins, and instead you have to discover bugs where you did a join but the two models each have a field called “description”…