3 ms·

I think that journey only feels inevitable if you start from the assumption that the application object model is the centre of the system. An alternative journe

I think that journey only feels inevitable if you start from the assumption that the application object model is the centre of the system. An alternative journey: Hmm – I should model the data according to the domain, not according to the shape my application objects happen to want. Hmm – maybe “related objects” are not things to auto-fetch, but relationships the database engine is already built to handle. Hmm – now that my schema matches my domain, complex problems can be solved with a few lines of SQL, saving me hundreds of lines of application code. Hmm – in fact, now I realise that many important operations can be performed without round-tripping the data through application code at all, saving me thousands of lines of application code.

watwut 3mo ago
None of your points remove the need to map db values to objects and to fetch related objects.
- simondotau 3mo ago
  If you just want to store and retrieve objects, and then store and retrieve "related" objects, what you want is an object store, not a relational database. You can use an ORM to shoehorn it into a relational database engine, but don't fool yourself into thinking that's the same thing as using a relational database engine properly. Obsessively cramming tabular data into objects is often unnecessary, and it bloats the code downstream of the database query. It then encourages the bad habit of performing data manipulation in code rather than directly in the database. "Fetch related objects" is a code smell. If any related data was needed, your original query should have already fetched it.
  - Izkata 3mo ago
    Problem is that doesn't work nicely in a one-to-many or many-to-many relationship - fetching it in the original query means deduplicating in the application code, or not fetching it and getting related rows afterwards. And that's one of the things ORMs are really good at.
    - simondotau 3mo ago
      For a video game, simulation, CAD program or other stateful program, loading an object graph can be natural. In that context, an object store, document database, serialized state, or ORM-backed persistence layer may be a reasonable fit. This isn't database design, it's application design. But in data management applications, the job is to derive specific information from stored facts. For that, SQL is not an implementation detail behind objects; it is the main abstraction. The whole point is to ask for the shape of data your application actually needs, not to arbitrarily hydrate objects and reinvent a bespoke querying engine on the client side. I can barely even remember the number of times that I've ripped an ORM out of a system because the code to interact with hydrated objects had devolved into a single-purpose database engine, a sprawling mess of code, seemingly well organised into objects, but ultimately wasteful. Often, de-duplicating in code is a perfectly fine solution, and significantly more performant than multiple round-trips. A join that repeats parent columns is not a flaw in SQL. It is only a problem if the application insists on rebuilding a nested object graph instead of asking for the shape of data it actually needs. If the data returned by the query does not match what you are presenting, the answer should not be to fetch a pile of related objects and interrogate them in memory. It is to use more SQL to further digest the data so that the result set more closely matches what you intend to present to the user.
mekoka 3mo ago
Using an ORM should not exempt you from designing your schema around the domain. If anyone thinks it's the case they're either using the ORM wrong, or using the wrong ORM, or perhaps creating the wrong ORM. Similarly, designing your schema to match the domain does not necessarily grant you the productivity boons of an ORM. Having (ab)used Postgres with and without ORM, I've never had a situation where the latter imposed any kind of design decisions on the schema. They're orthogonal concerns. Itself, the choice of using an ORM tends to be motivated by experience with certain requirements in the business logic. I love SQL, but when having to deal with API resources and their various representations, marshaling, validation, options, etc, it's difficult -- and to say the least, impractical -- to stay principled to the "no-ORM" and "raw-SQL" mottos.
- simondotau 3mo ago
  ORMs and schema design are not fully orthogonal. A database schema and an ORM model can be conceptually separated, but in practice they influence each other. And even if you are vigilant, knowing that you'll use an ORM will cause you to obsess about things which satisfy the ORM at the expense of good modelling. TLDR: Tooling pressure is a design pressure.

watwut 3mo ago

None of your points remove the need to map db values to objects and to fetch related objects.

simondotau 3mo ago
If you just want to store and retrieve objects, and then store and retrieve "related" objects, what you want is an object store, not a relational database. You can use an ORM to shoehorn it into a relational database engine, but don't fool yourself into thinking that's the same thing as using a relational database engine properly. Obsessively cramming tabular data into objects is often unnecessary, and it bloats the code downstream of the database query. It then encourages the bad habit of performing data manipulation in code rather than directly in the database. "Fetch related objects" is a code smell. If any related data was needed, your original query should have already fetched it.
- Izkata 3mo ago
  Problem is that doesn't work nicely in a one-to-many or many-to-many relationship - fetching it in the original query means deduplicating in the application code, or not fetching it and getting related rows afterwards. And that's one of the things ORMs are really good at.
  - simondotau 3mo ago
    For a video game, simulation, CAD program or other stateful program, loading an object graph can be natural. In that context, an object store, document database, serialized state, or ORM-backed persistence layer may be a reasonable fit. This isn't database design, it's application design. But in data management applications, the job is to derive specific information from stored facts. For that, SQL is not an implementation detail behind objects; it is the main abstraction. The whole point is to ask for the shape of data your application actually needs, not to arbitrarily hydrate objects and reinvent a bespoke querying engine on the client side. I can barely even remember the number of times that I've ripped an ORM out of a system because the code to interact with hydrated objects had devolved into a single-purpose database engine, a sprawling mess of code, seemingly well organised into objects, but ultimately wasteful. Often, de-duplicating in code is a perfectly fine solution, and significantly more performant than multiple round-trips. A join that repeats parent columns is not a flaw in SQL. It is only a problem if the application insists on rebuilding a nested object graph instead of asking for the shape of data it actually needs. If the data returned by the query does not match what you are presenting, the answer should not be to fetch a pile of related objects and interrogate them in memory. It is to use more SQL to further digest the data so that the result set more closely matches what you intend to present to the user.

mekoka 3mo ago

Using an ORM should not exempt you from designing your schema around the domain. If anyone thinks it's the case they're either using the ORM wrong, or using the wrong ORM, or perhaps creating the wrong ORM. Similarly, designing your schema to match the domain does not necessarily grant you the productivity boons of an ORM. Having (ab)used Postgres with and without ORM, I've never had a situation where the latter imposed any kind of design decisions on the schema. They're orthogonal concerns. Itself, the choice of using an ORM tends to be motivated by experience with certain requirements in the business logic. I love SQL, but when having to deal with API resources and their various representations, marshaling, validation, options, etc, it's difficult -- and to say the least, impractical -- to stay principled to the "no-ORM" and "raw-SQL" mottos.

simondotau 3mo ago
ORMs and schema design are not fully orthogonal. A database schema and an ORM model can be conceptually separated, but in practice they influence each other. And even if you are vigilant, knowing that you'll use an ORM will cause you to obsess about things which satisfy the ORM at the expense of good modelling. TLDR: Tooling pressure is a design pressure.