I have been a “Relational Database Practitioner” for more than a few years now. Starting with xBase tools (dBase, FoxPro), then DB2/2 (DB2 on OS/2, the good old days), and eventually onto a decade of Microsoft SQL Server. Recently I have been looking into PostgreSQL as a low cost 1, capable option.
When the “NoSQL” movement began, I like many in my field was skeptical. Much of my career was defined by projects that involved taking a “mess of data”, stored in a variety of formats, and coalescing it into something useful. The idea of storing data in a system that did not enforce data integrity through constraints, types, and a fixed schema seemed like a step in the wrong direction. I was also unsure if these new technologies were actually based on new ideas. Looking at document storage engines like CouchDB, I recalled days at shops that ran business applications on Lotus Notes.
It is also worth noting that many shops I have worked in tend to be monotonic. They base all efforts on a single platform or vendor, in an attempt to control complexity and cost. The only development options were those that were part of the small set of tools available with through the purchased subscription. Unfortunately, experience has taught me that when your tools are limited, often so are the quality of your solutions. A open mind should come with an open toolset.
At my current company, I find myself in an environment that not only utilizes a variety of technologies, but also challenges the points above. We manage data in a range of tools, some relational, some non-relational (and some very non-traditional). We also do not limit platforms to a single vendor. When projects are launched, decisions are made based on the viability of a technology to the solve the issue at hand. All vendors are an option; both commercial and open-source tools can be evaluated.
During a personal trip I took the opportunity to attend MongoDC, a single day conference put on by the purveyors of MongoDB. Here I was pleased to find not only a good bit of information about the database, its operation, and the very enthusiastic company behind it, but a large segment of the audience who were like me - relational practitioners looking for ways to make life easier - and perhaps a bit more "fun". A larger than expected segment of the audience were not rabid RDBMS haters, but those looking to solve more problems with more options. In other words, these were relational DBAs with an open mind.
Thus like others I challenge some of the thoughts in the “NoSQL” movement. I do not see non-relational databases as a wholesale replacement for traditional RDBMS platforms. I see them as a complement. There are cases where the performance implications of using joins due to normalization and rigid schemas can present scalability problems, where an easily implemented scale-out approach can solve. But on the other hand, there are cases where validation of data at the database level is of critical importance; transactions that cross tables are required, acknowledgement that data has been written to disk is critical. This is where the safeguards of an RDBMS are a requirement. Thus both approaches are valid, depending on the needs of a particular application, or layer of a system.
Like the static vs dynamic debate, or the Vi vs Emacs wars, the winners are those who choose what works best, each time they are faced with a problem to solve. In the concept of “using the right tool for the job”, I prefer instead to think of the moniker as #NotOnlySQL. Others I work with do too.