8 ms·

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 t

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.
- randomdata 3y ago
  > SQL isn't meant to be used without joins. Agreed. There was nothing to suggest otherwise. Did you not bother to read anything before replying? > "users" and "posts" in the example are not unrelated. They are related as per the graph, but that does not make them related in a relation. These are not equivalent models. After all, if they were suitably related in a relation you wouldn't have two tables in which to join. They would already exist in one relation. A simple `SELECT * FROM kitchen_sink` would do. > On the contrary there are very good reasons for doing exactly that. Yes, we went over them in detail. How did you end up here without reading a single word? > consequently it's not true that there's no business joining them. That's right, there is a good reason to join them: To overcome the overhead problem, better known as the n+1 problem. That would still be a hack if using an idealized system, or even a practical system that focuses on minimizing said overhead, like SQLite. In fact, the SQLite docs even tell you should not resort to such hacks while using SQLite as it is not necessary. > there's nothing inherently wrong with it That's right. Nobody said there was anything wrong with it. I even explicitly stated it was a good solution in many cases. I still don't understand how you managed to get here without reading a single thing. > the people who created GraphQL said what they meant and this isn't it I also said what I meant, but that didn't stop you from going off to la-la land. What makes you so sure you understood what they said when you can't even manage this simple conversation? > In my view, you are causing real harm but spreading false information on this subject. You haven't even read the discussion... But go on, let's assume I spread some falsehood. What harm has been caused?
  - dventimi 3y ago
    > There was nothing to suggest [that SQL isn't meant to be used without joins]. Did you not bother to read anything before replying? This you? "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" > Yes, we went over [the very good reasons for joining "users" and "posts"] in detail You literally wrote, "Logically, users and posts are distinct relations as it pertains to that example. They have no business being joined here." > That's right, there is a good reason to join them: To overcome the overhead problem, better known as the n+1 problem That's not right. That is not the reason to use joins. > That would still be a hack if using an idealized system, or even a practical system that focuses on minimizing said overhead, like SQLite. Joining tables in general and joining these tables in particular is not a hack. > In fact, the SQLite docs even tell you should not resort to such hacks while using SQLite as it is not necessary. Evidence or it didn't happen. > there's nothing inherently wrong with [a nested data type like XML or JSON] You also wrote, "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." Look, I read your comments many times despite your multiple incorrect assertions that I did not. If I haven't understood you perfectly, well in my defense it's because I'm dealing with gibberish like this. It sure seems like you're insinuating there's some kind of problem using SQL to generate the response for GraphQL queries and your reasoning if we can call it that seems to rest in part on the fact that a SQL query returns just one relation. Yes, that's true, but no, that is not a problem for generating the responses for GraphQL. > I also said what I meant [about the purpose of GraphQL] You said, "GraphQL doesn't need to be, nor is it meant to be, powerful. Its only purpose in life is to roll up multiple actions into a single response made from a single request" No, rolling up multiple actions into a single response isn't the only reason GraphQL was created. > You haven't even read the discussion. Wrong. Do you always try to take the easiest way out when your reasoning is subjected to scrutiny? > What harm has been caused [by my comments]? Oh, I don't know. How about by promulgating the idea that joins are somehow a "hack" for starters?

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.

randomdata 3y ago
> SQL isn't meant to be used without joins. Agreed. There was nothing to suggest otherwise. Did you not bother to read anything before replying? > "users" and "posts" in the example are not unrelated. They are related as per the graph, but that does not make them related in a relation. These are not equivalent models. After all, if they were suitably related in a relation you wouldn't have two tables in which to join. They would already exist in one relation. A simple `SELECT * FROM kitchen_sink` would do. > On the contrary there are very good reasons for doing exactly that. Yes, we went over them in detail. How did you end up here without reading a single word? > consequently it's not true that there's no business joining them. That's right, there is a good reason to join them: To overcome the overhead problem, better known as the n+1 problem. That would still be a hack if using an idealized system, or even a practical system that focuses on minimizing said overhead, like SQLite. In fact, the SQLite docs even tell you should not resort to such hacks while using SQLite as it is not necessary. > there's nothing inherently wrong with it That's right. Nobody said there was anything wrong with it. I even explicitly stated it was a good solution in many cases. I still don't understand how you managed to get here without reading a single thing. > the people who created GraphQL said what they meant and this isn't it I also said what I meant, but that didn't stop you from going off to la-la land. What makes you so sure you understood what they said when you can't even manage this simple conversation? > In my view, you are causing real harm but spreading false information on this subject. You haven't even read the discussion... But go on, let's assume I spread some falsehood. What harm has been caused?
- dventimi 3y ago
  > There was nothing to suggest [that SQL isn't meant to be used without joins]. Did you not bother to read anything before replying? This you? "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" > Yes, we went over [the very good reasons for joining "users" and "posts"] in detail You literally wrote, "Logically, users and posts are distinct relations as it pertains to that example. They have no business being joined here." > That's right, there is a good reason to join them: To overcome the overhead problem, better known as the n+1 problem That's not right. That is not the reason to use joins. > That would still be a hack if using an idealized system, or even a practical system that focuses on minimizing said overhead, like SQLite. Joining tables in general and joining these tables in particular is not a hack. > In fact, the SQLite docs even tell you should not resort to such hacks while using SQLite as it is not necessary. Evidence or it didn't happen. > there's nothing inherently wrong with [a nested data type like XML or JSON] You also wrote, "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." Look, I read your comments many times despite your multiple incorrect assertions that I did not. If I haven't understood you perfectly, well in my defense it's because I'm dealing with gibberish like this. It sure seems like you're insinuating there's some kind of problem using SQL to generate the response for GraphQL queries and your reasoning if we can call it that seems to rest in part on the fact that a SQL query returns just one relation. Yes, that's true, but no, that is not a problem for generating the responses for GraphQL. > I also said what I meant [about the purpose of GraphQL] You said, "GraphQL doesn't need to be, nor is it meant to be, powerful. Its only purpose in life is to roll up multiple actions into a single response made from a single request" No, rolling up multiple actions into a single response isn't the only reason GraphQL was created. > You haven't even read the discussion. Wrong. Do you always try to take the easiest way out when your reasoning is subjected to scrutiny? > What harm has been caused [by my comments]? Oh, I don't know. How about by promulgating the idea that joins are somehow a "hack" for starters?