NoSQL is even more arcane. It's like the Tower of Babel. Since the beginning, NoSQL developers have each tried to imagine the best language possible, but they have very different imaginations. This hotbed of experimentation is good -- until you try to jump between tools. A query for CouchDB is expressed as a pair of JavaScript functions for mapping and reducing. Early versions of Cassandra used a raw, low-level API called Thrift; newer versions offer CQL, an SQL-like query language that must be parsed and understood by the server. Each one is different in its own way.
Each tool doesn't just have its own idiosyncrasies, it sports an entirely different philosophy and way of expressing it. There are no easy ways to switch between data stores and you're often left writing tons of glue code just to give yourself the option of switching in the future. This may not be too difficult when you're stuffing pairs of keys and values into the system, but it can grow increasingly aggravating the more complexity you introduce.
NoSQL hard truth No. 5: Schema flexibility is trouble waiting to happen
One of the great ideas from the NoSQL model is not requiring a schema. In other words, programmers don't need to decide in advance which columns will be available for each and every row in a table. One entry may have 20 strings attached to it, another may have 12 integers, and another might be completely blank. The programmers can make the decision whenever they need to store something. They don't need to ask permission of the DBA, and they don't need to fill out all the paperwork to add a new column.
All that freedom sounds intoxicating, and in the right hands it can speed development. But is it really a good idea for a database that might live through three teams of developers? Is it even workable for a database that might last beyond six months?
In other words, the developers might want the freedom to toss any old pair into a database, but do you want to be the fifth developer to come along after four have chosen their own keys? It's easy to imagine a variety of representations of "birthday," with each developer choosing his or her own representation as a key when adding a user's birthday to an entry. A team of developers might imagine almost anything: "bday," "b-day," "birthday".
The NoSQL structure offers no support to limit this problem because that would mean reimagining the schema. It doesn't want to harsh on the mellow of the totally cool developers. A schema would get in the way.
The fact is that adding a column to a table isn't a big deal, and the discipline might actually be good for the developer. Just as it helps to force developers to designate variable types, it also helps to force developers to designate the type of data attached to a column. Yes, the DBA may force the developer to fill out a form in triplicate before attaching that column, but it's not as bad as dealing with a half-dozen different keys created on the fly by a programmer.
NoSQL hard truth No. 6: No extras
Let's say you don't want all of the data in all of the rows, and you want the sum of a single column. SQL users can execute a query with the SUM operation and send one -- just one -- number back to you.
NoSQL users get all of the data shipped back to them and can then do the addition themselves. The addition isn't the problem because it takes about the same amount of time to add up the numbers on any machine. However, shipping the data around is slow, and the bandwidth required to ship all that data can be expensive.
