57 ms·

This is specifically just a problem with all ORMs. They attempt to solve the object-relational mismatch and fail because these two concepts (sets of tuples and

This is specifically just a problem with all ORMs. They attempt to solve the object-relational mismatch and fail because these two concepts (sets of tuples and graphs) are completely orthogonal.

jbverschoor 4y ago
No it's not.. you can and will easily have the same problem with SQL if you're not fetching beforehand.. I bet wordpress (or many plugins) is/are so slow exactly because of this. ORMs will even make it easier to write more efficient queries is many cases.
- hinkley 4y ago
  There are too many questions to make any absolute statements. You hint at a couple here. Specialization of requests reduces data transport, but increases testing surface area and drastically reduces caching options - including within the database. Years ago we discovered that our bottleneck in Oracle was being caused by query cache evictions (worse, in 9i only queries currently in the cache could run, so new queries were blocking in the query planner. I'm not sure if this was ever fixed.) One of the important uses of etags within your infrastructure is to allow you to incorporate data manipulation into your caches. If your functions are deterministic you can store the results of a calculation, instead of the source data for that calculation. Cache hits then don't just save bandwidth, they also save computation, which reduces the sequential parts of the response, fighting Amdahl's Law.
- Arch-TK 4y ago
  If you intentionally write poor code with plain SQL you will have the same problem as the auto-generated poor code of a lot of ORMs? Yes? I don't think Wordpress is relevant here in any way. If the code is poorly written and has N+1 queries problems then it is either poorly written or is trying to half-ass an ORM. Lastly, I would like a lot of citations to prove to me that ORMs produce more efficient queries. What produces more efficient queries in all my experience is a good understanding of relational databases, better query planners and better database design.
- chc 4y ago
  This was very much a problem for WordPress back in its "glory days." I had to go in and optimize a lot of stuff to get our website's performance to be sub-5s. (I haven't worked with WordPress in years, so I can't comment on its current state, but I wouldn't be surprised if this is still a thing.)
fabian2k 4y ago
This is not a problem with all ORMs. This is caused by lazy loading the related data when it is accessed, which is not how all ORMs work. If your ORM requires you to define the included related data explicitly, you won't have this particular problem.
- Arch-TK 4y ago
  And an ORM which eagerly loads all related data before it is accessed will have a different but related problem. I'm actually not aware of any ORM which tries to do more than trivial guessing of when data needs to be eagerly loaded. There is no easy way of solving this problem within an ORM without either causing a different problem or without leaking the abstraction a lot and requiring lots of additional complexity to annotate what you want the ORM to actually do.
  - Lapsa 4y ago
    real fun begins when random Cartesian products shits up all your RAM
  - fabian2k 4y ago
    In EF Core for example you have to specify which relations to include, either using ".Include()" or transforming the entire query with a "Select()". In the latter case this works pretty much automatically as long as you stay within the kinds of expressions EF Core can translate to SQL. There is a different performance problem lurking with this design though. You have to decide whether to tell EF Core to do a query per relation or everything in one query. The single query is very efficient for many simple cases and ensures consistency, but it can fail spectacularly if you have a very large number of relations. This is a pretty significant footgun, but if you really don't want to be bothered with this you can just always use split queries. ORMs can't really abstract over all performance considerations. They are convenient, but they can't fully hide what the database is doing under the hood.
    - deleted 4y ago
      [deleted]
hgsgm 4y ago
Tuples are Objects Graphs are Relations. ORM (or GTM if you like) helps you navigate your Graph of Tuples.
- Arch-TK 4y ago
  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).
avereveard 4y ago
proper orm allow you to specify how to process relationships, best one on a per query basis and not on a per model basis. then they aggregate the table resulting from the join presenting a deduplicated view of the root object and all the related one fetched.
- Arch-TK 4y ago
  This is a major abstraction leak and is very rarely as simple as you describe it. The only time I've seen it be this simple is with people who design their databases entirely around an ORM and in that case they're already leaving a large amount of performance on the table which you can no longer recover by reaching behind the scenes to help the ORM figure out what it needs to do.

This is specifically just a problem with all ORMs. They attempt to solve the object-relational mismatch and fail because these two concepts (sets of tuples and graphs) are completely orthogonal.

jbverschoor 4y ago

No it's not.. you can and will easily have the same problem with SQL if you're not fetching beforehand.. I bet wordpress (or many plugins) is/are so slow exactly because of this. ORMs will even make it easier to write more efficient queries is many cases.

hinkley 4y ago
There are too many questions to make any absolute statements. You hint at a couple here. Specialization of requests reduces data transport, but increases testing surface area and drastically reduces caching options - including within the database. Years ago we discovered that our bottleneck in Oracle was being caused by query cache evictions (worse, in 9i only queries currently in the cache could run, so new queries were blocking in the query planner. I'm not sure if this was ever fixed.) One of the important uses of etags within your infrastructure is to allow you to incorporate data manipulation into your caches. If your functions are deterministic you can store the results of a calculation, instead of the source data for that calculation. Cache hits then don't just save bandwidth, they also save computation, which reduces the sequential parts of the response, fighting Amdahl's Law.
Arch-TK 4y ago
If you intentionally write poor code with plain SQL you will have the same problem as the auto-generated poor code of a lot of ORMs? Yes? I don't think Wordpress is relevant here in any way. If the code is poorly written and has N+1 queries problems then it is either poorly written or is trying to half-ass an ORM. Lastly, I would like a lot of citations to prove to me that ORMs produce more efficient queries. What produces more efficient queries in all my experience is a good understanding of relational databases, better query planners and better database design.
chc 4y ago
This was very much a problem for WordPress back in its "glory days." I had to go in and optimize a lot of stuff to get our website's performance to be sub-5s. (I haven't worked with WordPress in years, so I can't comment on its current state, but I wouldn't be surprised if this is still a thing.)

fabian2k 4y ago

This is not a problem with all ORMs. This is caused by lazy loading the related data when it is accessed, which is not how all ORMs work. If your ORM requires you to define the included related data explicitly, you won't have this particular problem.

Arch-TK 4y ago
And an ORM which eagerly loads all related data before it is accessed will have a different but related problem. I'm actually not aware of any ORM which tries to do more than trivial guessing of when data needs to be eagerly loaded. There is no easy way of solving this problem within an ORM without either causing a different problem or without leaking the abstraction a lot and requiring lots of additional complexity to annotate what you want the ORM to actually do.
- Lapsa 4y ago
  real fun begins when random Cartesian products shits up all your RAM
- fabian2k 4y ago
  In EF Core for example you have to specify which relations to include, either using ".Include()" or transforming the entire query with a "Select()". In the latter case this works pretty much automatically as long as you stay within the kinds of expressions EF Core can translate to SQL. There is a different performance problem lurking with this design though. You have to decide whether to tell EF Core to do a query per relation or everything in one query. The single query is very efficient for many simple cases and ensures consistency, but it can fail spectacularly if you have a very large number of relations. This is a pretty significant footgun, but if you really don't want to be bothered with this you can just always use split queries. ORMs can't really abstract over all performance considerations. They are convenient, but they can't fully hide what the database is doing under the hood.
  - deleted 4y ago
    [deleted]

hgsgm 4y ago

Tuples are Objects Graphs are Relations. ORM (or GTM if you like) helps you navigate your Graph of Tuples.

Arch-TK 4y ago
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).

avereveard 4y ago

proper orm allow you to specify how to process relationships, best one on a per query basis and not on a per model basis. then they aggregate the table resulting from the join presenting a deduplicated view of the root object and all the related one fetched.

Arch-TK 4y ago
This is a major abstraction leak and is very rarely as simple as you describe it. The only time I've seen it be this simple is with people who design their databases entirely around an ORM and in that case they're already leaving a large amount of performance on the table which you can no longer recover by reaching behind the scenes to help the ORM figure out what it needs to do.