3 ms·

When I think of SQL, I think of relational databases where they were created and most commonly used. What queries return are not tables, but a relation that can

When I think of SQL, I think of relational databases where they were created and most commonly used. What queries return are not tables, but a relation that can be composed of data from one or more tables. What this paper is then saying is "What if SQL returned something other than a relation?" That question is being answered by all non-relational DBs being made. An example of one might be a graphdb that could return a graph with nodes, edges and properties thereof. If we want to stay within relational dbs, then we're saying that we want a single statement to return multiple relations. That sounds something like GraphQL query to me which is stitching of the relational parts.

fyrn_ 3y ago
SQL queries return data from tables. The abstract does mention that one downside of this is that the result of the query has to be constructed in memory, resulting in a lot of copying. This is particularly apparent for joins, where some join types can produce much more data than all their input tables combined. I don't see how this is "return something other than a relation" they are pretty specific about what they mean and what benefits it can bring
- karmakaze 3y ago
  > Our approach has clear semantics, i.e. our extended SQL returns subsets of all tables with only those tuples that would be part of the traditional (single-table) query result set, however without performing any denormalization through joins. Yes, that sounds just like a GraphQL connection result with associated nested connections. I believe that there's link deduplication for GraphQL which can also be enabled to avoid the copies. The main difference is avoiding multiple round-trips--one for each table--which within a datacenter network doesn't add a whole lot of latency compared to the time serving those queries and some can also be done in parallel.
da_chicken 3y ago
> What this paper is then saying is "What if SQL returned something other than a relation?" No, I think it's closer to "hey guys, remember that idea that domains don't need to be primitive data types?"
ako 3y ago
You don’t need graphql for that, modern sql databases that support json documents already support something like this. In Postgres, either return nested json structures, or nested arrays. For an example see: https://shusson.info/post/building-nested-json-objects-with-postgres https://shusson.info/post/building-nested-json-objects-with-... Also supported by some ORMs like JOOQ: https://blog.jooq.org/nesting-collections-with-jooq-3-14s-sql-xml-or-sql-json-support/ https://blog.jooq.org/nesting-collections-with-jooq-3-14s-sq...

fyrn_ 3y ago

SQL queries return data from tables. The abstract does mention that one downside of this is that the result of the query has to be constructed in memory, resulting in a lot of copying. This is particularly apparent for joins, where some join types can produce much more data than all their input tables combined. I don't see how this is "return something other than a relation" they are pretty specific about what they mean and what benefits it can bring

karmakaze 3y ago
> Our approach has clear semantics, i.e. our extended SQL returns subsets of all tables with only those tuples that would be part of the traditional (single-table) query result set, however without performing any denormalization through joins. Yes, that sounds just like a GraphQL connection result with associated nested connections. I believe that there's link deduplication for GraphQL which can also be enabled to avoid the copies. The main difference is avoiding multiple round-trips--one for each table--which within a datacenter network doesn't add a whole lot of latency compared to the time serving those queries and some can also be done in parallel.

da_chicken 3y ago

> What this paper is then saying is "What if SQL returned something other than a relation?" No, I think it's closer to "hey guys, remember that idea that domains don't need to be primitive data types?"

ako 3y ago

You don’t need graphql for that, modern sql databases that support json documents already support something like this. In Postgres, either return nested json structures, or nested arrays. For an example see: https://shusson.info/post/building-nested-json-objects-with-postgres https://shusson.info/post/building-nested-json-objects-with-... Also supported by some ORMs like JOOQ: https://blog.jooq.org/nesting-collections-with-jooq-3-14s-sql-xml-or-sql-json-support/ https://blog.jooq.org/nesting-collections-with-jooq-3-14s-sq...