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.

Most cutting-edge developers love the idea of using so-called NoSQL databases.  Here is a helpful summary by my friend and colleague, Guy Harrison, that shows some of the big reasons behind their popularity.  While this is, in fact, largely a technical decision, there are a few things the business users need to understand.

One of the concessions made in the NoSQL world is around something called "Consistency".  This term is part of a well-known acronym to anyone who works with relational databases called: ACID.  The A, I, and D can remain largely part of the developer's black box because they are pretty "black and white", but Consistency is another matter.

Consistency is the vaguest of the four terms in ACID and I've seen it take on a couple of different definitions over the years.  Therefore, an example is in order so we can understand a particular nuance that merits attention by the business user.

Suppose you have an application that records a transaction on an e-commerce site.  In a strictly "Consistent" database environment, once the transaction was made, every corresponding aspect of the application would immediately reflect that change.  For example: inventory, user purchase history, and the financial transaction are all updated at the same time.  Guaranteed.

But in the world of NoSQL, we have something called "Relaxed Consistency", also known as "Eventual Consistency".  Using this paradigm, the database says: "I'll eventually get around to making sure everything looks the same.  Just chill out in the meantime."  And because of that, you can end up with inconsistent views of data, depending on which part of the application you are using.

Now, if you are a business user trying to get your head around this, your first thought might be "WHAT!? Never!"  But don't panic.  It's actually not a bad concept, and implementing it allows the system to scale in ways that are otherwise difficult-to-impossible.  In fact, odds are that you experience eventual consistency all the time in applications you use everyday such as your bank, social websites, or favorite e-commerce site.

Now for the big question: What part of the application is allowed to have eventual consistency?  This is something that you absolutely should not leave solely to the developer's discretion.  First there needs to be a thorough understanding of where latency can occur throughout the application, then the business stakeholder is the one who should decide if it is acceptable to the end-user experience.  The last thing you want is a negative surprise for your end users after the system is up and running.

In many of the first systems that used NoSQL databases, the developers were exactly in tune with the needs of their end-users.  As (and if) they become mainstream, this is likely to not be the case.  For years business users assumed consistency in their apps, but that should no longer be the case.  This is an area where the developers have to open their black box a bit to ensure happy end users.

I was in a discussion with a guy whom I consider to be an above average technologist.  He did a cursory investigation of some of the new databases on the market, among them MongoDB and CouchDB.  I was asking him what he saw as the biggest benefit of these document databases, and part of his answer surprised me:  "Well, and obviously they are very good for storing documents."  What kind of documents, I asked.  "You know, Word docs, Excel spreadsheets, that kind of thing.

Huh?

This served as another reminder to me of why it's important to stay up on these technologies in a way that goes beyond the buzzwords.  For the record, that is not the way documents are defined in today's document databases.  The documents are records of a sort, with fields and values, such as FirstName="Billy", LastName="Bosworth".

One reason (among many others) that they have become popular is because they make life very easy on developers.  They are simple to set up, and very flexible in the way they can be populated.  This means a developer doesn't need to spend time on complex data model changes as the needs of the application change.  They data structures are designed to be completely flexible from "document" to "document" in the database.

We'll talk more about these technologies later, but for now, this encounter served as a good reminder that there are still a lot of folks trying to get their head around these new technologies -- even ones that you may think have it down pat.  Ask lots of questions, then validate them with some basic research of your own.