RDBMS among top inventions ever | Hacker News Reader

RDBMS among top inventions ever

26 pointstabtab5 comments

This Register article: http://www.theregister.co.uk/2015/10/18/so_just_what_is_the_third_great_invention_of_all_time

raises the idea that the RDBMS (relational database) is among the most influential inventions ever.

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.

It outlasted and out-competed its competitors such as hierarchical and navigational databases, object databases, and even survived the "no-sql" movement (fad?) by making relatively minor changes to scale better.

It's the "Office Space" Milton of IT: Does most the real work, stuck in the basement, lacks a snazzy interface, and gets no respect.

View on HN

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.

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.

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

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

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.

Reply on news.ycombinator.com