Stonebraker: Send Relational DBMSs to the Home for Tired Software

You know, every couple of weeks an article like this comes up on HN or Slashdot predicting the end of the RDBMS. I don't deny that special purpose data stores can offer great performance improvements in some applications. But there is a reason that RDBMSs are celebrating their 40th birthday (as the article mentions). They are flexible, cheap (except for Oracle and DB2) and easy to manage.<p>My guess is that we will still be reading about the imminent death of the relational database another 40 years from now.

As long as they don't throw out the underlying idea that data can be deconstructed then reorganized into a form that adheres to mathematic principles, set theory and predicate logic in the case of RDBMS's, and from that you can perform logical operations on it that allow you to derive new, additional information from it. I think that was the major breakthrough of Relational Theory, hopefully that is built on, rather than thrown out.<p>Speaking of which, Chris Date, Hugh Darwen and some others were talking about a significant extension or evolution of the relational database, called the transrelational database, several years ago. Anyone heard of any progress on that front lately?

Software Engineering would progress a lot farther as a discipline if we weren't so preoccupied with throwing out the "old" to make room for the "new".<p>My definition of "legacy" code: code that is field-tested, has a low defect rate, and generally works.

This is just a brief summary of the Michael Stonebraker's piece "The End of a DBMS Era (Might be Upon Us)" which appeared on HN a few days ago. As far as I can tell it adds nothing new, am I missing something?

I think this article makes some good points. In fact there are times when I've been very frustrated at the "We can't to better than RDBMS" attitude many times. Particularly that time we were storing a tree in a table. Specialized data stores are very neat.<p>I do however think there will always be a good place for the traditional RDBMS. For instance, there are times when I'm creating that I don't know what the layout of the data will need to be, and where the optimizations will be most needed, so I back an app with Postgres. Should I need to expand later, it will be easier as I have actual data to work with.<p>I guess the point I'm trying to make is: unless you know for sure that your data will benefit from a different model (e.g. known performance needs, or a better conceptual mapping), not using an RDBMS seems like a premature optimizaton.

It seems as a database engineer, I am going to have to bulk up my skills in non-RDBMS technologies, even if just to be able to say "yes, I am very familiar with &#60;random non-SQL DBMS&#62; and it's not an appropriate solution to this problem".

I don't understand, I thought relational DBMS were left for the dogs many years ago. . .<a href="http://en.wikipedia.org/wiki/Dbms#End_1970s_SQL_DBMS" rel="nofollow">http://en.wikipedia.org/wiki/Dbms#End_1970s_SQL_DBMS</a>

<i>In the online transaction processing (OLTP) market, a lightweight main memory DBMS beats a row store by a factor of 50.</i><p>I'm confused -- what does main memory vs. row store have to do with relational vs. non-relational?

The actual article was already on here:<p><a href="http://news.ycombinator.com/item?id=680881" rel="nofollow">http://news.ycombinator.com/item?id=680881</a>