2 ms·

> 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

> 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_19h 3y 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.
- randomdata 3y 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?

int_19h 3y 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.

randomdata 3y 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?