Some misconceptions about NoSQL

So up front: I know this question sounds like a classic flame, however I'm honest about it, and the similarity to flame means I have yet to see an answer that I am satisfied with, as the discussions degenerate quickly. Anyway:<p>What is non-relational data? I have been under the impression for a long time that datasets all have internal relationships, be they semantic or other, and that relational databases are systems to store and query data based on the relationships. Even a key value store defines an explicit relationship.<p>When I first learned about databases, the class was about Normal Forms and Relational algebra, with rdbms thrown in as an example. These 2 key concepts are methods of working with data in a subtle and nuanced way -- a way strongly based on set and/or category theory. SQL it always seemed to me to be a decent extension to this, a DSL specifically designed to work on sets vs individual pieces of data. In that I found it elegant. Now this doesn't mean SQL is perfect, I get that, in a lot of cases it is clunk or worse. Nor does it mean that the underlying datastore needs to model data to exactly follow the relationships that describe it. And in light of CAP vs ACID views on data, a lot of exploration of this space makes sense. None of this includes a concept of relational vs non-relational data. In fact I view these systems as potential new building blocks of relational sytems.<p>So this has turned longer than I originally thought, but badk to the main question: what is non-relational data?

Great post, it is important to make clear that NoSQL is not just about performances. For instance now that I'm used to Redis lists and sets I feel strange when I'm using an SQL DB and I've a problem when to just pushing or popping stuff is the trivial thing to do.<p>Of course SQL databases are very useful and a great tool for many domains. It is also not a balanced view to think that SQL databases are to trow away. Sometimes the table-based data model, with the querying power of SQL, is just the way to go for many kind of problems, or in addition to a different kind of DB.

The term NoSQL is catchy but wrong. Some databases with strong theory backing them up, are fall under the NoSQL umbrella and others which are ad hoc and a huge step backwards are too.<p>I think the ultimate lesson we've re-learned is to use graph, hierarchical, and relational databases in an appropriate manner and to make engineering tradeoffs around consistency as needed. NoSQL is a crappy name for this lesson.

While the "NoSQL" moniker is catchy, misconceptions are inevitable so long as this category is defined more by what it isn't rather than what it actually is. What is NoSQL all about aside from scalability, performance, key/value access or support for non-relational data? This article doesn't clearly say.

Steve Derkote and I have just related a new graph database with a filesystem like REST API:<p>VertexDB: <a href="http://github.com/stevedekorte/vertexdb" rel="nofollow">http://github.com/stevedekorte/vertexdb</a>