undefined | Better HN

0 pointsint_19h2y ago0 comments

It took that position because it was what the first viable RDBMS used, pretty much. Similar to how JavaScript became the standard PL for browsers.

The simplest SQL queries map perfectly to relational algebra, so I'm still unclear as to what you had in mind. The two major deviations that SQL has over strict relational algebra are non-uniqueness of rows in a table, and NULL. The first one rarely comes up in practice, and any bag of non-unique rows can be trivially mapped to a bag of unique tuples simply by adding synthetic IDs to them. And SQL NULL semantics is widely considered to be a mess even by many users of SQL itself. With respect to performance, NULLs can be implemented very cheaply while optimizing their relational equivalent (1:0-or-1 relation) requires a little bit more effort on the DB side, but it's still such a simple pattern that I don't see a problem here.

0 comments

3 comments · 1 top-level

randomdata2y ago· 2 in thread

> It took that position because it was what the first viable RDBMS used

Then wouldn't we be using LINUS today rather than SQL? "Viable" is quite hand wavy, so maybe you don't consider MRDS to have been viable enough for some reason. But even once relational databases were moving into the mainstream, there was no clear winner between SQL and QUEL for quite a long time. Even what is arguably the most beloved DBMS of all time, Postgres, picked the QUEL horse originally.

But SQL was generally considered easier to understand for the layman, perhaps in large part because it was less strict with respect to the theory. This may be another reason why it won.

> Similar to how JavaScript became the standard PL for browsers.

I don't know how similar that is. I'm not sure there was ever another realistic alternative you could have ever chosen. The only real attempt to change that, VBScript, was likely to not work half the time due to not having the right dependencies on the host system, making it impractical for real-world use.

Maybe not anymore, but for a time there were practical alternatives to SQL.

> The first one rarely comes up in practice

The first one is the most common source of SQL bugs I see out in the wild. Complex joins can become quite unintuitive because of it. Nothing you can't learn around, and of course work around, but something you have to always be mindful of. As such, I'm not sure I agree that it rarely comes up in practice.

Not to mention I see a lot of people making use of that fact. It is a useful quality in practical applications. It also comes up quite a bit in practice because, frankly, often you don't want rows to be unique.

int_19hOP2y ago

In practical applications, you pretty much always have synthetic row IDs in cases where there aren't any natural ones.

I think it would be more helpful if you could give a specific example of a simple SQL query that does not map nicely to a relational expression, since it's kind of hard to discuss the specifics in these vague terms.

randomdata2y ago

I don't understand what you are looking for. There is no specific SQL query I know of that could not expressible in relational calculus in some manner. But that also has nothing to do with the discussion.

The discussion is about why SQL became the standard. Being first is not it. It wasn't first. It was second, but QUEL came along hot on its heels before SQL established itself. It was approximately another decade after that before SQL solidified dominance.

- Was there a specific technical reason to choose SQL over QUEL/LINUS?

- Was there a specific human reason to choose SQL over QUEL/LINUS?

- Was it just random chance and if we were to do it all over again we are just as likely to see QUEL/LINUS become the standard instead?

j / k navigate · click thread line to collapse