3 ms·

Sets of tuples and graphs of objects are fundamentally incompatible and I have not found a single ORM which didn't completely fail to pave over this fundamental

Sets of tuples and graphs of objects are fundamentally incompatible and I have not found a single ORM which didn't completely fail to pave over this fundamental incompatibility. The object-relational impedance mismatch is not just something I came up with to shit on ORM. It is a well understood and widely known phenomenon which ORM users often like to insist on pretending doesn't exist. To claim that sets of tuples are the same as object graphs is like claiming that you have solved the halting problem. Feel free to claim that the impedance mismatch is small enough that a sufficiently advanced ORM might successfully abstract it away, I don't think this claim is defensible either but on the other hand claiming that the OR impedance mismatch doesn't exist makes me think you have no idea what problem an ORM actually solves. It certainly makes me wonder how you would justify the size and complexity of every ORM out there.

8note 4y ago
Isn't an adjacency list a set of 2-ples? That's a set of tuples that defines a graph
- Arch-TK 4y ago
  Try re-creating a relational database in a graph database or vice versa by applying this approach and report back. I promise you that if you put a graph in a SQL database or vice versa you will end up with absolutely abysmal performance unless you explicitly go out of your way to special case everything into being performant.
nightski 4y ago
The problem isn't the mismatch of the data structures. Imo it comes down to lazy loading and that's about it. Using lazy loading to navigate relationships is where the impedance mismatch manifests and it is completely avoidable (basically a do at your own risk, danger ahead type of scenario).
- Arch-TK 4y ago
  How is it avoidable? It's a necessary part of using an ORM. Moreover, you're severely understating the complexity of dealing with how to load data through an ORM and how to control the underlying queries. SQL is already a perfectly adequate language for describing how to query relational data, by putting a effectively a graph query language in front of it and adding a translation layer you immediately need an immense amount of special casing, the common cases might be handled by a sufficiently sophisticated ORM but once you veer even slightly outside the realm of a basic hello world application which accesses a database you are immediately hit with a wave of all the complexity which results from the abstraction leaking. Every time I've personally dealt with an ORM or seen code which deals with an ORM, the amount of unnecessary hassle which is required just to get the ORM to do what you want it to do certainly outweighs any imagined benefit of using it. If you think SQL is hard to write then you're putting the blinders on to claim that ORMs are easier to deal with. If you have never hit upon these sorts of issues then you must have never actually needed to do anything non-trivial and performant with an ORM.
  - nightski 4y ago
    I primarily use EF, although I have used many others in the past. You are right that not all ORMs are equal, not even close. But with EF at least those problems aren't really a big deal. You are right that SQL is perfectly adequate - great actually. I generally think in terms of SQL before loading data with a Linq query. Often I'll do a query that projects to a model/dto. Or if I do need to load the entity and it's relations, I'll craft it just like I would in SQL. You can load the desired related entities first and then when you load the main entity they get auto populated since they are in the context. It's easy to build exactly what you need this way. So why use an ORM? Well for one, on commands if I load an entity I get change detection for free. I get bulk inserts/updates/deletes for free (Using ef extensions). I get strongly typed queries for free. I'm able to find all references to a particular table or column across my entire code base with a single click. I can build up queries dynamically via linq. There's a lot of huge benefits that save a lot of time.

8note 4y ago

Isn't an adjacency list a set of 2-ples? That's a set of tuples that defines a graph

Arch-TK 4y ago
Try re-creating a relational database in a graph database or vice versa by applying this approach and report back. I promise you that if you put a graph in a SQL database or vice versa you will end up with absolutely abysmal performance unless you explicitly go out of your way to special case everything into being performant.

nightski 4y ago

The problem isn't the mismatch of the data structures. Imo it comes down to lazy loading and that's about it. Using lazy loading to navigate relationships is where the impedance mismatch manifests and it is completely avoidable (basically a do at your own risk, danger ahead type of scenario).

Arch-TK 4y ago
How is it avoidable? It's a necessary part of using an ORM. Moreover, you're severely understating the complexity of dealing with how to load data through an ORM and how to control the underlying queries. SQL is already a perfectly adequate language for describing how to query relational data, by putting a effectively a graph query language in front of it and adding a translation layer you immediately need an immense amount of special casing, the common cases might be handled by a sufficiently sophisticated ORM but once you veer even slightly outside the realm of a basic hello world application which accesses a database you are immediately hit with a wave of all the complexity which results from the abstraction leaking. Every time I've personally dealt with an ORM or seen code which deals with an ORM, the amount of unnecessary hassle which is required just to get the ORM to do what you want it to do certainly outweighs any imagined benefit of using it. If you think SQL is hard to write then you're putting the blinders on to claim that ORMs are easier to deal with. If you have never hit upon these sorts of issues then you must have never actually needed to do anything non-trivial and performant with an ORM.
- nightski 4y ago
  I primarily use EF, although I have used many others in the past. You are right that not all ORMs are equal, not even close. But with EF at least those problems aren't really a big deal. You are right that SQL is perfectly adequate - great actually. I generally think in terms of SQL before loading data with a Linq query. Often I'll do a query that projects to a model/dto. Or if I do need to load the entity and it's relations, I'll craft it just like I would in SQL. You can load the desired related entities first and then when you load the main entity they get auto populated since they are in the context. It's easy to build exactly what you need this way. So why use an ORM? Well for one, on commands if I load an entity I get change detection for free. I get bulk inserts/updates/deletes for free (Using ef extensions). I get strongly typed queries for free. I'm able to find all references to a particular table or column across my entire code base with a single click. I can build up queries dynamically via linq. There's a lot of huge benefits that save a lot of time.