
RDBMS among top inventions ever - tabtab
This Register article: 
http:&#x2F;&#x2F;www.theregister.co.uk&#x2F;2015&#x2F;10&#x2F;18&#x2F;so_just_what_is_the_third_great_invention_of_all_time<p>raises the idea that the RDBMS (relational database) is among the most influential inventions ever.<p>Its effect on society is far less visible to the average person on the street than say the Internet or nukes, but it runs most the key systems and infrastructure of society. It allows quick access to billions of data items via almost any attribute. Before, you had to be selective about which attributes you could search, group, and sort on.<p>It outlasted and out-competed its competitors such as hierarchical and navigational databases, object databases, and even survived the &quot;no-sql&quot; movement (fad?) by making relatively minor changes to scale better.<p>It&#x27;s the &quot;Office Space&quot; Milton of IT: Does most the real work, stuck in the basement, lacks a snazzy interface, and gets no respect.
======
sparasur
Absolutely well deserved. Particularly SQL, the simple and consistent
standards based interface to data that is uniform across all DB vendors and
Operating systems. The fact that RDBMS and particularly SQL has stood the test
of time is both testimony and reason for the unreasonable amounts of unlocked
productivity in the applications programming industry. And these include all
web applications. Without this, almost every application would be re inventing
its own database, just like we see in so many no-sql applications.

------
sgeneris
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
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
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.)

