SQL seems to be the last(ish) remaining vestige of the misguided idea of “English-like” syntax, which began with COBOL and also included HyperTalk and AppleScript. Such languages can often be very easy to read, but are hard to write because the syntax is far less flexible than it appears to be. For example in SQL’s SELECT statement the sub-clauses like FROM, ORDER BY, LIMIT need to be in a specific order.
Yep, it could be better. But, after 15 years of doing this, I fully agree with the author of this great rant (previously posted here, I believe) - SQL is so common place because everyone knows it, and it’s been around for 50 odd years.
PromQL is a particular query language I want to fire into the sun.
Also, SQL transcends the engineer/business divide, BAs write SQL, support specialists write SQL, and so we’re all speaking a common language. If I started using SaneQL, and wrote a query to help a BA, then now I’ve got to translate it to SQL for them.
It’s the lingua franca of querying, like English is the lingua franca of airline pilots. And of course because history has a sense of humour, neither of them are actually Lingua Franca.
It’s a language everyone understands, it’s been around since the seventies, and it’s reasonably standardized.
As someone who has had to care about SQL dialect differences professionally, the idea that SQL is “standardized” is a lie. Even something as simple as “if you sort a column, are nulls first or last, and how do you override the default” or “how do you quote a column name if it’s a keyword” differs across dialects!
Hell, even in that post, they mention “Postgres/Redshift”; Redshift has a full list of differences between it and Postgres that vary from “no support for array constructors” to “key constraints are not enforced” and warns you about the “often subtle differences” between the two.
It’s a bit of an odd situation because there is an ISO standard, and it’s even regularly updated (most recently SQL:2023), but nobody fully adheres to the standard, and many DBs don’t even make much of an effort.
Yeah, the only real way to figure out how a dialect behaves is to look at its documentation. (And even then it isn’t reliable; at least one major one has a reserved keyword that isn’t in the published list…)
It might help if the SQL standard was not locked away behind the ISO paywall, ISO’s strict gatekeeping around standards committee membership, and the secrecy rules governing committee discussions.
Note: The post title is different from the original video title ‘Towards Sanity in Query Languages’ since I saw the rule around reducing hyperbole in titles.
I like this; reminds me of LINQ.
SQL seems to be the last(ish) remaining vestige of the misguided idea of “English-like” syntax, which began with COBOL and also included HyperTalk and AppleScript. Such languages can often be very easy to read, but are hard to write because the syntax is far less flexible than it appears to be. For example in SQL’s SELECT statement the sub-clauses like FROM, ORDER BY, LIMIT need to be in a specific order.
There’s always Inform7!
Yep, it could be better. But, after 15 years of doing this, I fully agree with the author of this great rant (previously posted here, I believe) - SQL is so common place because everyone knows it, and it’s been around for 50 odd years.
PromQL is a particular query language I want to fire into the sun.
Also, SQL transcends the engineer/business divide, BAs write SQL, support specialists write SQL, and so we’re all speaking a common language. If I started using SaneQL, and wrote a query to help a BA, then now I’ve got to translate it to SQL for them.
It’s the lingua franca of querying, like English is the lingua franca of airline pilots. And of course because history has a sense of humour, neither of them are actually Lingua Franca.
As someone who has had to care about SQL dialect differences professionally, the idea that SQL is “standardized” is a lie. Even something as simple as “if you sort a column, are nulls first or last, and how do you override the default” or “how do you quote a column name if it’s a keyword” differs across dialects!
Hell, even in that post, they mention “Postgres/Redshift”; Redshift has a full list of differences between it and Postgres that vary from “no support for array constructors” to “key constraints are not enforced” and warns you about the “often subtle differences” between the two.
It’s a bit of an odd situation because there is an ISO standard, and it’s even regularly updated (most recently SQL:2023), but nobody fully adheres to the standard, and many DBs don’t even make much of an effort.
Yeah, the only real way to figure out how a dialect behaves is to look at its documentation. (And even then it isn’t reliable; at least one major one has a reserved keyword that isn’t in the published list…)
It might help if the SQL standard was not locked away behind the ISO paywall, ISO’s strict gatekeeping around standards committee membership, and the secrecy rules governing committee discussions.
Note: The post title is different from the original video title ‘Towards Sanity in Query Languages’ since I saw the rule around reducing hyperbole in titles.