3 ms·

> Roads lead back to SQL because it became a de facto industry standard for "relation-like" stuff. But what was in question is why SQL is the standard. Did it

> Roads lead back to SQL because it became a de facto industry standard for "relation-like" stuff. But what was in question is why SQL is the standard. Did it take that position because of its deviation? If so, that would suggest the theory doesn't just work. Without actually profiling, I suspect that the deviation allows some real-world optimizations to take place, enabling SQL databases to be faster than something with strict adherence to the theory. That would be a good reason why you might have to choose SQL over a strict alternative. > Can you give an example of a query that cannot be expressed well in relational algebra Seems not. CloudFlare blocked the submission, complaining that I was submitting a SQL query, which it thinks is a security concern for some reason... In lieu, just think about what a relation is and how SQL is not relational. Even some of the simplest select queries you can imagine can demonstrate your request.

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

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.

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