SQL is now 50 What is coming next to the query language? | Hacker News Reader

SQL is now 50 What is coming next to the query language?

coderoasis.com

18 pointsSudoSH21 comments

This article is pure garbage. Here are some of its sins: * It says that SQL was introduced in 1974 and could be used for web applications (the web was invented in 1989). * Then it calls AI “Artistical Intelligence”. * And it never even talks about the topic of its title: what’s next for SQL.

It also claims that SQL is hard to learn, while in my experience it is quite easily picked up by many, including less tech-savy.

It is hard to master, but that goes for pretty much any skill.

It really is mind boggling, how come the forced bloat did not yet reach SQL. Of course people try very hard to "innovate" (ehm, the proper word would be poison) in this space, by adding more abstractions, confuse things with overly complex solutions or create syntax that just can't be remembered.

So if you have the feeling that you need to elevate yourself above the crowd by complicating things, package it and sell it as an invention, meaning: this is somehow too easy to remember and use, then of course there are myriads of ORMs and the like that bring you this very much needed panacea that is unneeded complexity for your programs. If you feel the need, then just enter the neverending forest and we'll hope you will get lost in it and never return.

Window functions very much fits the pattern of "forced bloat".

I am struggling to find any content in this article -- it seems like it was written by an AI

Only real content I can find is the original SEQUEL paper linked in the article: https://dl.acm.org/doi/10.1145/800296.811515?ref=coderoasis....

The article does not answer "what comes next?". I was expecting topics like GraphQL and others but article jumps into AI and NLP which are very different discussions rather than standard protocol to access data

Times up. LLMs are uniquely suited to convert data requests to SQL at compile-time. All ORMs will converge on this feature “scan your table layout and generate smarter queries with Knexjs Pro+” - one can see it coming.

My mother raised me as a broke single mother because she could write SQL. I bought a home in my California home town because I could write good SQL and tune my.cnf. I suppose my toddler will never SELECT * FROM.

I wish it weren’t so, but it’s always felt a bit silly, hasn’t it? “Hey Siri, People own many Widgets and belong to one Team” is coming. Why would we want the future of computing not to obscure database operations? Why should our grandchildren care about shards? Let it all die.

The reason the big focus on LLMs generating SQL was that SQL is somewhat more natural language like? It doesn't mean that LLMs generate sensible or even correct SQL.

I work at a big company with big data and sometimes trawl the query logs to speed things up and recently noticed an uptick in WTF queries that, I suspect, have had some AI 'assistance' ;)

Absolutely not. For example, there is literally nothing at all in common between a Postgres query and a Clickhouse query except some very basic surface-level syntax.

(And even then lots of things are incompatible, e.g., count(*) vs count())

You don't have to write `count()` in ClickHouse - `count(*)` is also ok.

... while `count()` makes more sense from the engineering perspective: it is an aggregate function that takes zero number of arguments.

I personally prefer `count()`, but when my friends write `count(*)` or even `COUNT(*)`, they are still my friends.

The count() invocation is a small but excellent feature in ClickHouse. There are many other great dialect extensions. -If combinators are another great example. [0] SQL would be a better language if there had been more innovation focused on code usability over its long history.

[0] https://clickhouse.com/docs/en/sql-reference/aggregate-funct...

The best thing to happen in sql in recent times is snowflake starting to allow an extra comma in the end of the expression list lol. Now I can ask all the DBAs in my life to stop formatting their queries comma first!

Yeap BigQuery also recently added allowing some trailing commas, although not everywhere e.g. not inside structs etc. Definitely makes things much easier.

There are lots of relaxations they could make that would help tooling and templated stuff, e.g. allowing FROM before SELECT and allowing multiple WHEREs and allowing comparision/hashing of structs and arrays and things.

About the only rss feed I ever see is the BigQuery announce one; they actually make interesting incremental improvements all the time, e.g. recently added a RANGE type and functions (although it works for dates and timestamps, but not integers; argh, so close...)

Not only Snowflake: https://play.clickhouse.com/play?user=play#U0VMRUNUIAogIDEsC...

Is there really anything missing from SQL? I guess adding a few semantic shortcuts like Postgres' SELECT DISTINCT ON (x) are useful.

But otherwise this feels like asking what's coming next for Algebra.

One use-case that other systems support is doing queries with a time budget..Eg find me all columns that match a search within 50ms.

Not sure now to do that with postgres.

According to ISO.org, which normalized only 2 DB query languages (the first one of which is SQL), it’s GQL (for graph query language).

GQL was normalized in April 2024. Here is the link: https://www.gqlstandards.org/

This article appears to be AI-created and also, it doesn't answer its own title question.

Update: Checked out the host site. There's zero human fingerprints on any content made there. It all looks AI generated and completely anonymous.

Take a look at the SQL statements your app uses, replace them with your own code, three months later, your code is much larger, harder to understand, and may not even be any faster. I will be happy for SQL to carry on as it is.

It can be 100.

Reply on news.ycombinator.com