I am rather comfortable writing concrete schemas with explicit primary keys, foreign keys, indexes, views and stored procedures. For queuing I use a NoSQL solution called: Redis.
Recently I heard a web-application development talk where the presenter said he used MongoDB and Node.JS (server-side) with AngularJS on the client-side.
This significantly minimises data conversion; as JSON is used natively across the board.
Are the performance gains from data consistency enough of a reason to develop in NoSQL, rather than relational?
PS: Should note that MongoDB uses BSON, so that could be interchanges for something like CouchDB (correct me if I'm wrong, but that stores as plain JSON)
Best Answer
I think your question presupposes a certain way of looking at things. Your fundamental tradeoff with NoSQL is a tradeoff between declarative ad hoc reporting and fast and loose inputs. This tradeoff is unacceptable for many (maybe most) businesses, and so "rather than relational" I think is the wrong way to look at it. Even folks like Martin Fowler advocate something different.
My recommendation is always to start relational and then add NoSQL adjuncts to the rdbms to handle velocity issues when those arise.