[leandrod]

Sorry, it is wrong. SQL is not baſed on ſets, but bags, which are quite different and more complicated. And, by the way, CTEs are a feature of ISO SQL, not only of MS SQL Server.

Finally, entity‐relationſhip is not terribly practical as a model, but as diagrammiŋ.

[jacobolus]

(It’s off-topic, but why the long esses and engs? The latter are not letters in English, and the former haven’t really been used in at least a century.)

[pradocchia]

This is true, SQL does not require everything to be a set, strictly speaking, but internally many platforms append a unique row identifier to bags, so that they can be processed as sets.

I often wish platforms would expose their internal calculus in a separate syntax, so we wouldn't have to work through the SQL translation layer. Algebraic operators would be nice too.

[leandrod]

Ðat may be true, but what platforms do internally ſhould not affect ðeir flavours of SQL.

In oðer words, internal implementation as ſets do not make SQL ſet‐baſed.

[pradocchia]

No argument there (ðere?), SQL is an unfortunate language.

[cturner]

Do you have any thoughts about why there has been no challenge to the SQL syntax? We can easily imagine notations based on relational algebra and relational calculus emerging that could be interpreted at the same levels of an RDBMS as SQL, yet I've not seen anyone attempt it. A good PhD topic for someone?

[encoderer]

SQL was designed to make data accessible to non-programmers. That's why it lacks more advanced/obscure syntax.

And the reason why it's stuck is the same story that you can tell over and over about standards.

[shaunxcode]

APL? (seriously)