In a previous post I touched on a technical reason that business users should be in communication with developers using a NoSQL database.  Here is reason number 2: Data Access.

Relational databases have been around for so long, and have become so common and ubiquitous, that nobody really gives any thought to getting data out of the database.  Most end users are capable of writing SQL, even if it's through a graphical type query builder found in something like Access.  Even without that, the row/column nature of a relational database lends itself nicely to exports into Excel, where it can easily be manipulated and browsed.

When it comes to NoSQL databases, you cannot make the assumption that having access to that data is going to be easy.  The reason these databases have been grouped under the heading of "NoSQL" (even though I think that's a bad way to characterize them) is because they did not provide a SQL interface.  Instead, you need to use a programing language to retrieve the data, and when you put that condition on it, the number of people who can access it just got a whole lot smaller.

There are armies of people out there who know SQL that live shoulder-to-shoulder with the business analysts.  When a NoSQL database gets implemented, there might be a lot of shoulder-shrugging going on for a while as to how to get the data out.  Just like the first reason I covered, this does not mean it is a show-stopper.  Rather, it is just something you need to address up front.

Disclaimer: At the time of this writing, I work for a company called Quest Software.  We created a tool called "Toad for Cloud Databases" that helps solve this problem.  While this post might seem oddly self-serving, the truth is that this problem is what led us to build the product in the first place.  So whether you choose to use a 3rd-party tool or not, the problem is still real and still something you should give some thought to early in the process.