I sometimes read that NoSQL solutions are a better fit for prototyping applications as they don’t require any upfront data modeling work. I must confess that I pretty much disagree with that.
Even if we are talking about key-value stores or document databases, not to mentioned column-based stores and graph databases, the fact that they make it easy to throw in some data is not really an advantage (not to mention that you’d be able to take the same route using a RDBMS). This approach will just hide away any future issues and postpone discovering the real merits of the chosen NoSQL solution.
While we’ve learned over time that we cannot blindly apply GoF patterns and/or RDBMS data modeling patterns, I believe that each NoSQL project community would benefit a lot from having around some data modeling patterns. Just to exemplify what I mean, you can check these discussions to see that even simple data modeling problems can raise questions.
I’ll end up with a quote from MongoDB CTO, Eliot Horowitz:
I think the first question you have to ask about any database these days is: “What’s the data model?”
adding only that the next questions should be about access patterns of your application.
MongoDB seems to already have in place such documentation. For example: (↩)
I’d really love to hear from you about similar docs from other NoSQL projects.
-  While I’m pretty sure there are more such discussions, I have only picked two: (↩)