4 ms·

Given that SQL DBMSs are so far from a true RDBMS, imagine where we would have been today if true RDBMSs rather than SQL ones had been implemented.

lovich 8y ago
Would you mind expanding on that point? I know a bit about relational databases and more about SQL, but I never knew heard anything about SQL not being a true RDBMS. I'd be interested in hearing where they diverged
- tabtab 8y ago
  The biggest complaint is that SQL allows "bag output", meaning the result table (output) doesn't necessarily have to have or echo a unique key (singular or compound). Dr. Codd's definition of "relational" wouldn't allow such. ("Bag" is a type of data structure.) I've argued there are times when you want to suppress the key, such as giving data to an outside customer where you don't want them to have the internal key. Query languages such as REL that don't allow "bag output" require silly gyrations to remove the key from the output. As a compromise I have proposed SQL require a clause "ALLOW BAG" before it allows bag output. This would prevent most inadvertent bags. (I'd like similar for "ALLOW CARTESIAN" to prevent inadvertent Cartesian joins. It's a far bigger actual problem than bags, in my experience.) I believe this comprise is good enough and avoids having to totally throw out SQL and start over. (SQL has other annoyances, but REL doesn't solve most in my opinion.)
tabtab 8y ago
I've been round and round on the "pure RDBMS" issue, and I have to conclude purity makes little practical difference. Systems and data already have so much "noise" for other reasons outside of technology that cleaning up that corner won't change anything. Some purity-centric clauses and changes could be made to SQL if it really mattered, but it won't be the silver bullet of productivity and accuracy that purists claim.

4 ms·

Given that SQL DBMSs are so far from a true RDBMS, imagine where we would have been today if true RDBMSs rather than SQL ones had been implemented.

by sgeneris 8y ago

lovich 8y ago
Would you mind expanding on that point? I know a bit about relational databases and more about SQL, but I never knew heard anything about SQL not being a true RDBMS. I'd be interested in hearing where they diverged
- tabtab 8y ago
  The biggest complaint is that SQL allows "bag output", meaning the result table (output) doesn't necessarily have to have or echo a unique key (singular or compound). Dr. Codd's definition of "relational" wouldn't allow such. ("Bag" is a type of data structure.) I've argued there are times when you want to suppress the key, such as giving data to an outside customer where you don't want them to have the internal key. Query languages such as REL that don't allow "bag output" require silly gyrations to remove the key from the output. As a compromise I have proposed SQL require a clause "ALLOW BAG" before it allows bag output. This would prevent most inadvertent bags. (I'd like similar for "ALLOW CARTESIAN" to prevent inadvertent Cartesian joins. It's a far bigger actual problem than bags, in my experience.) I believe this comprise is good enough and avoids having to totally throw out SQL and start over. (SQL has other annoyances, but REL doesn't solve most in my opinion.)
tabtab 8y ago
I've been round and round on the "pure RDBMS" issue, and I have to conclude purity makes little practical difference. Systems and data already have so much "noise" for other reasons outside of technology that cleaning up that corner won't change anything. Some purity-centric clauses and changes could be made to SQL if it really mattered, but it won't be the silver bullet of productivity and accuracy that purists claim.