Things I want in a modern relational query language

zzdw about 22 hours ago 25 commentsRead Article on sporks.space

RU version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

62% Positive

Analyzed from 1046 words in the discussion.

Discussion (25 Comments)Read Original on HackerNews

scythmic_waves•about 1 hour ago

Some overlap here with some of my favorite essays on why SQL is lacking:

https://www.scattered-thoughts.net/writing/against-sql

That particular post ends with a wish-list of items so it's the most similar to the OP. But there are others on the site that I quite enjoy (click on the home icon and search "SQL" on the page).

My personal take is that SQL will continue to reign for a long time because of the how monumental the task of replacing it is due to the inherent complexity of databases. LLMs make this worse because they're really good at translating prose to SQL. Now that it matters less how annoying SQL is to programmers, SQL will become more like assembly over time: something mostly computers write because it's complicated for humans to deal with directly. This is deeply ironic given that SQL was ostensibly designed to read like prose, i.e. to be easy for humans.

reitzensteinm•3 minutes ago

LLMs are also very good at writing code for newly invented languages, especially if they can execute it and iterate. I strongly believe the barrier to switch languages is lowered in a post LLM world.

Ten years ago I was at a startup where we used Datomic, and it was okay, but six months in the sales team was like “ok how do I run SQL queries so I can triage leads”. We had no answer of course.

Today it would simply be: type what you want in natural language and we’ll generate the query with Claude.

I just tried one representative query from that startup against a hypothetical datalog query tool in Rust and it did just fine.

ljm•20 minutes ago

Rawdogging SQL when you're not a seasoned DB administrator basically makes an arcane art look occult.

Most people reach out towards an ORM or query building engine and otherwise don't really go far beyond the basic CRUD, joins, and some simple aggregations with groups. Since they try to be DB agnostic you'll rarely get an adaptor over CTEs or window functions or partitioning.

An LLM is great at exposing what a database is capable of doing with SQL and might even manage to navigate the most poorly designed of schemas. And it might even manage to design one to an acceptable standard if it has enough domain knowledge in its context.

mcc1ane•about 1 hour ago

https://www.geldata.com/blog/we-can-do-better-than-sql

(https://news.ycombinator.com/item?id=24106608, https://news.ycombinator.com/item?id=19871051)

bastawhiz•about 1 hour ago

As a meta comment, I can handle code blocks without syntax highlighting, and I can handle code blocks that wrap. But both together with long comments just turn into line noise. There's no longer any useful visual signal for how to read them. On my phone the code blocks are simply impossible to meaningfully parse.

tmoertel•about 1 hour ago

The problem with alternative query languages is that the people who have the most knowledge about creating queries and of the relational domains underlying their businesses are all experts in SQL. Introducing something else, then, means your most natural user base must migrate away from something they understand how to use well, and that's a hard sell.

So, until the ultimate query language is developed, I'll take SQL with pipes. It's an easy sell and good enough to eliminate 90% of my gripes about SQL.

taybin•42 minutes ago

This is exactly the same problem facing people trying to develop new music notations. In order to grasp the domain enough, they have to be experts in the existing music notation, and once you're an expert in it, the motivation to create something new goes away. From what I've seen, the people who want a new music notation are mostly people uncomfortable with sight reading.

AlotOfReading•23 minutes ago

Experts have been criticizing SQL since it was a proprietary IBM language. Take this typewritten rant from 1983 [0] as an example. And we've had better query languages for just as long, e.g. datalog. People really love SQL though, which I can only assume is because the vast majority of usecases are slight variations on SELECT * FROM table.

[0] https://courses.cs.duke.edu/spring03/cps216/papers/date-1983...

smitty1e•39 minutes ago

For example, Elastic. Much extra learning curve for little obvious gain.

I like to say, with zero research basis, that the New Shiny has to be an order of magnitude better than the Old Thing for people to say "Oh yeah, I gotta have that."

senfiaj•31 minutes ago

I wan't easier ways to work with nested structures, like relationships. All this flat table structure is a pain.

a2ff6eeb0•about 1 hour ago

This would have been interesting about a decade ago, but today AIs all know SQL, and I haven't written it myself in a while.

Since it seems like the quantity of training data dominates AI performance, and AI doesn't yet internalize experience with new tools, it seems like a bad idea to stray from the training set.

Without repeatable benchmarks, it feels like obsessing over a language's syntax and semantics feels a little like debating whether you write assembly using AT&T or Intel syntax.

ModernMech•about 1 hour ago

AIs would benefit from better query languages for the same reasons people would.

a2ff6eeb0•11 minutes ago

The difference is that the bulk of what an AI knows is baked in when it's trained, at least for now. There's no way for it to learn a language and improve with it.

3eb7988a1663•about 1 hour ago

Can someone explain to me why SQL error messages are so bad? I routinely have some monster query where the message is effectively, "Illegal syntax somewhere, dufus".

bawolff•31 minutes ago

I'd guess people just haven't put much effort into it. Lots of programming language compilers have absolutely terrible error messages. In SQL its usually just one line, so "somewhere" isn't that big a place.

klysm•about 1 hour ago

This sounds like a proper of the parser, rather than of the language

derriz•37 minutes ago

A long time ago, I had to write SQL parsers (for 3 of the most popular DBs at the time). It is a surprisingly difficult language to parse and disambiguate - particularly when having to deal with the warts of its variants. Sure it's not quite C++ but it's was easily the most annoying parser work I ever had to do. And in my experience, the trickier it is to parse a particular language, the more difficult it is to provide feedback to users in the form of helpful parse errors.

appplication•29 minutes ago

This is true, but the observation is still salient. There does seem to be some correspondence between languages with inherent friction and parsers that aren’t interested in being helpful. E.g. sometimes a user base just collectively decides they’re ok with some level of pain.

bri-holt•about 1 hour ago

This is an ultra compact relational query language designed for LLMs. https://memelang.net/11/

a2ff6eeb0•about 1 hour ago

What benchmarks did they use? It seems like on larger tasks, having the LLM be familiar with the language through a large volume of training data will compactness and tenseness.

See https://danluu.com/pl-tokens/

avmich•33 minutes ago

Why don't we have APL as the language here?

zoolo•about 1 hour ago

Check out CodeQL, it's a modern relational query language based on Datalog.

esafak•about 1 hour ago

Database engineers have to be the change they want to see and add support for newer query languages.

flir•28 minutes ago

The early-2ks crop of NoSQL solutions have all got SQL baked in now, haven't they?

Maybe when they've achieved wide adoption for a better language than SQL, they can work on getting rid of qwerty keyboards...

convolvatron•29 minutes ago

that is a pretty difficult place to apply leverage. if you don't support SQL you're at a big competitive disadvantage. because its a weird design with lots of sharp edges that's going to take a lot of your time - customers are going to be unhappy that you don't support the knobs and frills from their existing environment.

so you can certainly float an alternate QL on top of the same base, but its going to be hard to drive uptake. you can translate SQL to your internal variant, but oddities like group by are going to twist your internal model.

at this point I think its more interesting to start to deconstruct these large software systems like OSes and databases and move the composition of systems down a step.