I like the comparison of the design themes of relational modeling and NoSQL modeling as, respectively, "what answers do I have?" and "what questions do I have?"
Yes, a provocative thought. But I don't really buy it.
I think it's clearer to see the distinction between an information model and a storage model: The fundamental goal of an information model is to provide a mechanism to convert input information into output information. But if the model is so degenerate that it just echos back the same data in the same format that was put in (at a different time), then it's probably better to call it a storage model.
The relational model is a logic system that lets us use predicate calculus to infer from one set of propositions taken to be true, a second set which is by implication true. That is, it provides a means to obtain encoded answers in response to encoded questions applied to a body of encoded facts.
And a KV store is clearly a storage model.
And there are some in-between, such as the CouchDB document store, that can transform one body of information to another, but also pay attention to physical storage issues.
To me the key point is that in relational databases you describe - declaratively - the information you want and leave it to the database to figure out to retrieve it (x); whereas in most NoSQL databases you describe how to retrieve the information.
(x) this is not the entire truth, as SQL is actually a (somewhat) unfortunate mix between the declarative relational calculus and the procedural relational algebra.
I don't know enough to understand what makes relational algebra procedural. I read the "Haskell more successful cousin" article and I thought that the relational algebra part was what made SQL and Haskell similar.
