There is certainly plenty of activity in the nonrelational (“NOSQL”) db space right now. Almost every week a new variant seem to pop up claiming new functionality over its predecessors. This theme was covered in one of my previous posts ‘which freaking database should I use’
We know for noSQL projects the data model is not relational. But what is the data model? What is the right model?
There are many possibilities, the most popular of which are:
Key/Value. Pure key/value stores are blobs stored by key. At its simplest I think as Windows File Explorer as a key/value store – the key is the filepath; the value the MSWord document or whatever.
Tabular. Some projects use a Google BigTable-like data model which we call “tabular” here — or one can think of it as “multidimensional tabular”.
Document-Oriented. Typical of these are JSON-style data stores, and of particular interest to me MongoDB.
Graph DBs seem to have niche applications in social media and graph/
These are painstakingly summarised in this excellent viz
What is the right data model? Should there be standardization? Or is it really a case of horses-for-courses (with all the hidden costs that may pose)?
Key/value has the advantage of being simple. It is easy to make such systems fast and scalable. Con is that it is too simple for easy implementation of some real world problems. We’d like to see something more general purpose.
Tabular brings more flexibility. But why are we sticking to tables? Shouldn’t we do something closer to the data model of our programming languages? Tabular jettisons the theoretical underpinnings of relational algebra, yet we still have significant mapping work from program objects to “tables”. If I were going to work with tables, I’d really like to have full relational power.
The biased (?!) guys at 10gen who wrote this article obviously really like the document-oriented approach of Document DBs . The programming languages we use today, not to mention web services, map very nicely to say, JSON. A JSON store gives us an object-like representation, yet also is not tied too tightly to any one single language, which seems wrong for a database.