5 ms·

IMHO the ORM was an unfortunate choice for trying to develop a generalization about abstractions. SQL's declarative model has an impedance mismatch with impera

IMHO the ORM was an unfortunate choice for trying to develop a generalization about abstractions. SQL's declarative model has an impedance mismatch with imperative programming, ORMs attempt to deal with that mismatch. SQL hides complexity but Codd's goals when developing the relational model was to allow non programmers to access data. The design decisions and tradeoff analysis was massively different than just an abstraction targeting developers. There are many different persistence models that have vastly different tradeoffs, costs and benefits. Balancing integration and disintegration drivers are complex and can impact optimization in many ways.

imtringued 1y ago
ORMs with lazy loading are a bad example, because they are a performance optimization with regards to ORMs that do eager loading. Eager loading requires you to load all associations, which is even more expensive. The fallacy with lazy loading ORMs is that they often give you no or very poorly suited methods for specifying what needs to be loaded or not. Even when they do, the problem is that you cannot separate the data loading aspects from the querying aspects. You end up with data repository service classes that do "findBooksByYearWithAuthorAndSequels" rather than just "findBooksByYear" and a separate way for specifying "WithAuthorAndSequels" that doesn't require you to come up with a ridiculous naming scheme.
9rx 1y ago
> ORMs attempt to deal with that mismatch. Technically ORMs attempt to deal with the mismatch between relations[1] and the rich data structures (objects) general purpose programming languages normally allow expression of. Hence the literal name: Object-Relation Mapping. That SQL, the language, is declarative is immaterial. > but Codd's goals when developing the relational model was to allow non programmers to access data. That is unlikely. He was staunchly opposed to database vendors adding "veneer" to make use more friendly and considered SQL an abomination. Codd was dead set on mathematical purity, which is, I'd argue, also why his vision ultimately failed in practice as actual relational databases are too hard to understand for those not well versed in the math. [1] Technically tables, since we're talking about SQL, which isn't relational. But the mapping idea is the same either way.
- reaanb2 1y ago
  "Object-relational mapper" is a misnomer, they should be called network data model to SQL mappers. They're not primarily for mapping between different arrangements of the same data, but about recreating a network data model perspective. How many ORMs support composite primary keys and non-binary relationships? As you said, the challenge of understanding math is why the relational vision failed, but also why the industry keeps reviving the network data model.
  - 9rx 1y ago
    > How many ORMs support composite primary keys and non-binary relationships? Theoretically all. However, often ORM and query building are combined into a unified framework that links them together into a higher order abstraction. You may know this type of thing by names like the active record pattern or the data mapper pattern, with concrete implementations like ActiveRecord and Entity Framework. Such frameworks often make it difficult to use the ORM component in isolation (and even where that isn't the case, doing so largely defeats the purpose of using the framework anyway), and as such you become constrained by the limits of the query builder. I suspect that is what you are really thinking of.
    - reaanb2 1y ago
      EF is limited to binary relationships: https://learn.microsoft.com/en-us/ef/core/modeling/relationships https://learn.microsoft.com/en-us/ef/core/modeling/relations.... When entities are mapped to rows and relationships to foreign key constraints, it results in a network data model interpretation of SQL databases. The relational model is better conceptualized from a fact-oriented modeling perspective, in which entities map to values, domains to FK constraints, relationships to the association of two or more entity sets in a table, and rows represent propositions about entities rather than entities themselves. However, non-binary relationships don't easily translate into navigational data access (cf. Bachman's paper "The programmer as navigator" about the network data model) and a logical view is difficult for the non-mathematical programmer, while structs and pointers are naïvely easy to understand, that's why ORMs remain popular. The impedance mismatch is less about mapping flat to rich data structures than about the network data model vs fact-oriented perspectives and row-at-a-time vs batch data access.

imtringued 1y ago

ORMs with lazy loading are a bad example, because they are a performance optimization with regards to ORMs that do eager loading. Eager loading requires you to load all associations, which is even more expensive. The fallacy with lazy loading ORMs is that they often give you no or very poorly suited methods for specifying what needs to be loaded or not. Even when they do, the problem is that you cannot separate the data loading aspects from the querying aspects. You end up with data repository service classes that do "findBooksByYearWithAuthorAndSequels" rather than just "findBooksByYear" and a separate way for specifying "WithAuthorAndSequels" that doesn't require you to come up with a ridiculous naming scheme.

9rx 1y ago

> ORMs attempt to deal with that mismatch. Technically ORMs attempt to deal with the mismatch between relations[1] and the rich data structures (objects) general purpose programming languages normally allow expression of. Hence the literal name: Object-Relation Mapping. That SQL, the language, is declarative is immaterial. > but Codd's goals when developing the relational model was to allow non programmers to access data. That is unlikely. He was staunchly opposed to database vendors adding "veneer" to make use more friendly and considered SQL an abomination. Codd was dead set on mathematical purity, which is, I'd argue, also why his vision ultimately failed in practice as actual relational databases are too hard to understand for those not well versed in the math. [1] Technically tables, since we're talking about SQL, which isn't relational. But the mapping idea is the same either way.

reaanb2 1y ago
"Object-relational mapper" is a misnomer, they should be called network data model to SQL mappers. They're not primarily for mapping between different arrangements of the same data, but about recreating a network data model perspective. How many ORMs support composite primary keys and non-binary relationships? As you said, the challenge of understanding math is why the relational vision failed, but also why the industry keeps reviving the network data model.
- 9rx 1y ago
  > How many ORMs support composite primary keys and non-binary relationships? Theoretically all. However, often ORM and query building are combined into a unified framework that links them together into a higher order abstraction. You may know this type of thing by names like the active record pattern or the data mapper pattern, with concrete implementations like ActiveRecord and Entity Framework. Such frameworks often make it difficult to use the ORM component in isolation (and even where that isn't the case, doing so largely defeats the purpose of using the framework anyway), and as such you become constrained by the limits of the query builder. I suspect that is what you are really thinking of.
  - reaanb2 1y ago
    EF is limited to binary relationships: https://learn.microsoft.com/en-us/ef/core/modeling/relationships https://learn.microsoft.com/en-us/ef/core/modeling/relations.... When entities are mapped to rows and relationships to foreign key constraints, it results in a network data model interpretation of SQL databases. The relational model is better conceptualized from a fact-oriented modeling perspective, in which entities map to values, domains to FK constraints, relationships to the association of two or more entity sets in a table, and rows represent propositions about entities rather than entities themselves. However, non-binary relationships don't easily translate into navigational data access (cf. Bachman's paper "The programmer as navigator" about the network data model) and a logical view is difficult for the non-mathematical programmer, while structs and pointers are naïvely easy to understand, that's why ORMs remain popular. The impedance mismatch is less about mapping flat to rich data structures than about the network data model vs fact-oriented perspectives and row-at-a-time vs batch data access.