The article starts with a description/definition of 'key-value stores' vs 'document stores'... but doesn't clarify the difference, if any. When people say 'NoS

The article starts with a description/definition of 'key-value stores' vs 'document stores'... but doesn't clarify the difference, if any. When people say 'NoSQL', that doesn't preclude another kind of query language... I assume NoSQL to mean, roughly : - no traditional ansi RDBMS SQL - key-value store - graph-like / treelike data as first class citizen - map/reduce style operations - bundled with a dynamic lisp/python/ruby/javascript style general programming language. You'd have to agree that 'NoSQL' is a movement - ie. many people vocalizing their shared emotional frustration at the limits of SQL. Not theoretical limits, but practical ease of use and subjective syntactic inelegance. I personally identify with the movement, after having built traditional sql systems, preached data normalization etc., then slowly realising that this RDB approach is just really unwieldy and brittle. Moving from XML to JSON, from C++ to lisp languages.. this makes the ugly syntax of SQL really stand out : as blatantly as COBOL or FORTRAN do to someone who has read K&R. Maybe we havent found the right replacement... but we still know there has to be a better way. The term 'NoSQL' is subjective, undefined, fuzzy - but its a label for a real problem that needs solving, and groups together partial solutions.