> Connection centric: SQL's session-based transaction model is maladapted to modern cloud computing abstractions such as serverless, and is difficult to manage at scale.
There's nothing connection-centric at all to the language.
> Inflexibility of result structure: SQL is particularly inflexible in terms of control over response: A query result is always a set of tuples. A query is incapable of returning a rich structure [...]
Many modern SQL-based RDBMSes provide JSON support for this. Some support row/record values, which is -in SQL- more natural than JSON.
> Complicated, irregular syntax:
Well, few like the SQL syntax -- there is that. I wouldn't say it's complicated syntax though.
> [...] and allows only limited forms of composition.
CTEs and subqueries are the main methods of composition in SQL.
> Opaque, unpredictable performance:
Yes, well, yes, of course, because SQL is declarative. That the programmer gets little control over the query planner is part of the point of SQL. The query language really needs to be like this. What could and should be done however is to have a) ways of addressing parts of the query, b) ways of specifying out of band (i.e., not in the query) hints or requirements for parts of the query's planning.
I really would like to be able to:
- specify indexing for CTEs
- be able to pass in hints from outside
a query, like what table source to
make the "first" in a query plan,
what indices to use for specific
table sources, where constraints, etc.
> Rigid tabular data model: Despite the theoretical adaptability of the relational model to many domains, the flat, uniform structure the traditional SQL database imposes on records is especially rigid, forcing a significant amount of upfront design.
I don't agree that this is a problem. You have to design your schema? The horrors.
> Introducing new query patterns and schema evolution is fraught with a significant amount of operational risk. Combined, these hinder iterative application development and risk locking in bad data model design decisions.
This is not exactly not true of alternatives to SQL-based RDBMSes...
TFA makes very strained arguments.
There are good arguments for a new language, but there's no need to make strained arguments along the way -- it detracts from TFA.
There's nothing connection-centric at all to the language.
> Inflexibility of result structure: SQL is particularly inflexible in terms of control over response: A query result is always a set of tuples. A query is incapable of returning a rich structure [...]
Many modern SQL-based RDBMSes provide JSON support for this. Some support row/record values, which is -in SQL- more natural than JSON.
> Complicated, irregular syntax:
Well, few like the SQL syntax -- there is that. I wouldn't say it's complicated syntax though.
> [...] and allows only limited forms of composition.
CTEs and subqueries are the main methods of composition in SQL.
> Opaque, unpredictable performance:
Yes, well, yes, of course, because SQL is declarative. That the programmer gets little control over the query planner is part of the point of SQL. The query language really needs to be like this. What could and should be done however is to have a) ways of addressing parts of the query, b) ways of specifying out of band (i.e., not in the query) hints or requirements for parts of the query's planning.
I really would like to be able to:
> Rigid tabular data model: Despite the theoretical adaptability of the relational model to many domains, the flat, uniform structure the traditional SQL database imposes on records is especially rigid, forcing a significant amount of upfront design.I don't agree that this is a problem. You have to design your schema? The horrors.
> Introducing new query patterns and schema evolution is fraught with a significant amount of operational risk. Combined, these hinder iterative application development and risk locking in bad data model design decisions.
This is not exactly not true of alternatives to SQL-based RDBMSes...
TFA makes very strained arguments.
There are good arguments for a new language, but there's no need to make strained arguments along the way -- it detracts from TFA.