But What Does That Practically Mean?

One of the principle advocacy points used to pitch many NoSQL solutions is the flexibility of the schema. Whether it’s an amorphous binary blob in a key-value database, or a loosely structured JSON collection in a document-oriented database, the general benefit is that it’s up to you, and it remains flexible with each and every database entry. Contrasted against traditional databases where there is often significant up-front considerations of every table and column and relationship — choices that are very strictly enforced, reminding you of their presence each and every day — there is a compelling narrative that minus that up front investment you’ve saved yourself time and effort.

But the selling point has never convinced me (just as it didn’t convince me when the same thought process was behind the advocacy of “database within a database” solutions, an sql_variant serving all needs).

How do you write an application with no data structure How, practically, is the lack of a formal database schema a real benefit in the life cycle of an actual product, after the honeymoon period of “boy did I save time not having to consider a schema!” has passed?

It generally isn’t a benefit. Instead the emergent schema gets tightly bound with the application layer, the database benefit reduced to facilitating less expensive data model transitions (relative to the worst case of some relational models, with MySQL traditionally being a particularly bad implementation when you need to make schema changes on very large sets of data). The problem in this back-loaded model is that the database is often the longest-living part of the application, with many modern applications sharing the database descendant of implementations done decades ago, while the GUI is often wholesale rewrite after rewrite in completely differing technology stacks. Yet you lose all of the benefits of strong typing — to use a general language term — constraints.

It is, more often than not, a foolish assumption that a temporary gain will yield long term benefits, when the opposite is generally true.

The database world is hardly alone in these sorts of superficially-beneficial solutions. If you’ve worked on a development team for any length of time, you will have enjoyed the experience of having a participant who knows just enough to, essentially, be dangerous. Where vague, shapeless solutions cure all ills.

Mocks, Test Drive Development, Agile, Waterfall, MVC, Magical Data Engine. It’s silver-bullet time!

It isn’t that these solutions are bad in isolation — they are fantastic at the right time, place and situation (just as schema-free NoSQL databases most certainly have a place) — but the woefully ignorant application of them to the wrong problems render them project sabotage: It becomes a distraction that is worse than a simple time waste because it derides meaningful efforts. This destroys projects and teams when all improvements face the same barrage of inappropriate silver-bullet solutions.

In any case, it has been very odd seeing all of the coming-to-senses in the NoSQL space over the past year. I dare say that many of the posts that I authored previously have been proven out (and worth noting that since then I’ve done more with NoSQL solutions than many of the people who I debated with on those points).