4 ms·

> If it's smart, it will resolve the whole thing with one join. Yes, as a practical engineer that is what you would do to deal with the overhead you have encou

> If it's smart, it will resolve the whole thing with one join. Yes, as a practical engineer that is what you would do to deal with the overhead you have encountered in the datacenter, but you would realize that you are abusing SQL to hack around overhead issues. That is not what you would do in a less constrained environment. Logically, users and posts are distinct relations as it pertains to that example. They have no business being joined here. There is a place for joins, but that's not it. So already, for the simplest case imaginable, you are using SQL outside of the way it was designed to be used. Which is fine if it gets the job done. Purity can step to the side for the sake of engineering, of course. We are not purists here. But as the complexity ramps up, there will be a point where it stops being a decent tradeoff and enters a point of being ridiculous – where you've ended up recreating GraphQL... but poorly.

valenterry 3y ago
> Logically, users and posts are distinct relations as it pertains to that example. They have no business being joined here. There is a place for joins, but that's not it. So what would you do in your world? Run one SQL to get the post's ids and then run another query with that list to get the content for those posts?
- randomdata 3y ago
  If you were to use SQL as designed, with an idealized implementation, you would first query the users and then run a query for each user to retrieve the the corresponding posts. That is what the example given describes. I know that's not exactly practical in the real world. Maybe if you dataset is tiny you can get away with it, but any more you'll soon be killed by the overhead of all those queries in the datacenter, let alone over flaky networks. So, in the real world you have to find a workaround. Using a join here is a decent workaround with decent tradeoffs. You can condense what might be hundreds of queries into one. It does not come free. There is no free lunch. But the tradeoffs are acceptable in a lot of cases. But we're also talking about the simplest case imaginable. While it is a reasonable tradeoff for that simple example, those hacks don't scale particularly well as the complexity grows. SQL is not designed for one query to return everything and the kitchen sink.
  - valenterry 3y ago
    Okay, I think I understand now. I'm a bit surprised, since for me, joins are a very fundamental feature of SQL - but I understand where you come from if you see that differently. Thank you for the explanation.
    - randomdata 3y ago
      Joins are fundamental to where joins are a logical operation. But given the specific example of trying to pack unrelated datasets into one relation, to unpack them again on the client, to save on overhead costs is not at all what joins are designed for. What you are talking about is commonly known as the n+1 problem. It is a problem because the mathematically pure solution does not usually work in the real world due to real world overhead constraints. If computers operated in an idealized world the n+1 problem wouldn't exist, but we live in a harsh reality where not everything works out so perfectly. If joins were meant to be used this way, obviously it wouldn't be a problem in the first place... But it is a problem because that is not what joins are designed for, even if they can help deal with the problem in some cases. Obviously you can use things beyond what they are designed for, but in this case it only works in the small scale. Give us a complicated example and watch the nightmare unfold. Again, SQL is designed for working with the relational model. The example GraphQL schema is not relational. It describes a graph model. There is, as they say, an impedance mismatch. The closest approximation to a graph in the relational model is multiple relations, and multiple relations in SQL requires multiple queries. In SQL, one query always returns just one relation.
      - dventimi 3y ago
        I think you are wrong. I think you are "confidently wrong" as evidently the saying goes, on many points. - GraphQL isn't meant to bundle many operations together. People mean things and the people who created GraphQL said what they meant and this isn't it, or at least it isn't all of it. - SQL isn't meant to be used without joins and it isn't being abused by the presence of joins. - "users" and "posts" in the example are not unrelated. We were explicitly told by the author of the example that they ARE related. - consequently it's not true that there's no business joining them. On the contrary there are very good reasons for doing exactly that. - doing that--making those joins--is not a hack - while it's true that a SQL query returns only one relation, there's nothing inherently wrong with it being a relation over a nested data type like XML or GraphQL. In my view, you are causing real harm but spreading false information on this subject.
dventimi 3y ago
> you are abusing SQL to hack around overhead issues. > Logically, users and posts are distinct relations as it pertains to that example. They have no business being joined here. > There is a place for joins, but that's not it. > So already, for the simplest case imaginable, you are using SQL outside of the way it was designed to be used. I'm sorry. What?
- deleted 3y ago
  [deleted]
- randomdata 3y ago
  When confused, it is best to read the whole thing, not just arbitrarily chosen snippets.
  - dventimi 3y ago
    Why did you write this?
    - randomdata 3y ago
      Same reason why I write anything. Why would this be different?
      - dventimi 3y ago
        And yet not being a mind reader I won't know what your reason is until you tell me. You're not obliged to tell me what that reason is, of course, but so long as you don't say what that reason is, you fail to rule out the possibility that you don't actually have a reason.
        randomdata 3y ago
        Your suggestion that humans might do something without reason is intriguing. Tell us more, if you are so inclined.

valenterry 3y ago

> Logically, users and posts are distinct relations as it pertains to that example. They have no business being joined here. There is a place for joins, but that's not it. So what would you do in your world? Run one SQL to get the post's ids and then run another query with that list to get the content for those posts?

randomdata 3y ago
If you were to use SQL as designed, with an idealized implementation, you would first query the users and then run a query for each user to retrieve the the corresponding posts. That is what the example given describes. I know that's not exactly practical in the real world. Maybe if you dataset is tiny you can get away with it, but any more you'll soon be killed by the overhead of all those queries in the datacenter, let alone over flaky networks. So, in the real world you have to find a workaround. Using a join here is a decent workaround with decent tradeoffs. You can condense what might be hundreds of queries into one. It does not come free. There is no free lunch. But the tradeoffs are acceptable in a lot of cases. But we're also talking about the simplest case imaginable. While it is a reasonable tradeoff for that simple example, those hacks don't scale particularly well as the complexity grows. SQL is not designed for one query to return everything and the kitchen sink.
- valenterry 3y ago
  Okay, I think I understand now. I'm a bit surprised, since for me, joins are a very fundamental feature of SQL - but I understand where you come from if you see that differently. Thank you for the explanation.
  - randomdata 3y ago
    Joins are fundamental to where joins are a logical operation. But given the specific example of trying to pack unrelated datasets into one relation, to unpack them again on the client, to save on overhead costs is not at all what joins are designed for. What you are talking about is commonly known as the n+1 problem. It is a problem because the mathematically pure solution does not usually work in the real world due to real world overhead constraints. If computers operated in an idealized world the n+1 problem wouldn't exist, but we live in a harsh reality where not everything works out so perfectly. If joins were meant to be used this way, obviously it wouldn't be a problem in the first place... But it is a problem because that is not what joins are designed for, even if they can help deal with the problem in some cases. Obviously you can use things beyond what they are designed for, but in this case it only works in the small scale. Give us a complicated example and watch the nightmare unfold. Again, SQL is designed for working with the relational model. The example GraphQL schema is not relational. It describes a graph model. There is, as they say, an impedance mismatch. The closest approximation to a graph in the relational model is multiple relations, and multiple relations in SQL requires multiple queries. In SQL, one query always returns just one relation.
    - dventimi 3y ago
      I think you are wrong. I think you are "confidently wrong" as evidently the saying goes, on many points. - GraphQL isn't meant to bundle many operations together. People mean things and the people who created GraphQL said what they meant and this isn't it, or at least it isn't all of it. - SQL isn't meant to be used without joins and it isn't being abused by the presence of joins. - "users" and "posts" in the example are not unrelated. We were explicitly told by the author of the example that they ARE related. - consequently it's not true that there's no business joining them. On the contrary there are very good reasons for doing exactly that. - doing that--making those joins--is not a hack - while it's true that a SQL query returns only one relation, there's nothing inherently wrong with it being a relation over a nested data type like XML or GraphQL. In my view, you are causing real harm but spreading false information on this subject.

dventimi 3y ago

> you are abusing SQL to hack around overhead issues. > Logically, users and posts are distinct relations as it pertains to that example. They have no business being joined here. > There is a place for joins, but that's not it. > So already, for the simplest case imaginable, you are using SQL outside of the way it was designed to be used. I'm sorry. What?

deleted 3y ago
[deleted]
randomdata 3y ago
When confused, it is best to read the whole thing, not just arbitrarily chosen snippets.
- dventimi 3y ago
  Why did you write this?
  - randomdata 3y ago
    Same reason why I write anything. Why would this be different?
    - dventimi 3y ago
      And yet not being a mind reader I won't know what your reason is until you tell me. You're not obliged to tell me what that reason is, of course, but so long as you don't say what that reason is, you fail to rule out the possibility that you don't actually have a reason.
      - randomdata 3y ago
        Your suggestion that humans might do something without reason is intriguing. Tell us more, if you are so inclined.