So you can easily normalize multiple incoming JSON types to a single index (eg mix JSON data from different APIs into a single "column", etc.)
And that's not even getting into the reduce side. From [1] "if documents represent your company’s financial transactions, a view can answer the question of what the spending was in the last week, month, or year."
Also check out RavenDB (http://ravendb.net/). It's another JSON document database with JavaScript powered map/reduce indexes. One caveat is that RavenDB updates its indexes async. It's a type of eventual consistency. That means that after a write, an index may not immediately have the updated data. Depending on the application, this may or may not be acceptable.
The key is for some of the patterns to work, you need to be able to know your index queries come from the same database snapshot as your event feed, which is easier to do when you aren't in clustered mode.
- The aggregates are XML serializable entities persisted into tables using the XML datatype (fairly comparable to PostreSQL's JSON datatype).
- MSSQL has numerous methods for querying, updating, and reading from XML typed columns. They're certainly clunky, but they do work.
- To simplify querying and indexing, we created computed columns with a user defined function to query from the XML column. By marking these columns as persisted, the UDF is only executed and the column updated when the row is written. And as persisted, the computed columns can be included in normal indexes to improve performance.
A lot of folks may scoff at using XML, and especially MSSQL's XML datatype. But I will say that it works. And after you've built a simple foundation, developing your aggregates and working with them almost becomes a breeze.
And as far as XML versus JSON... it almost doesn't matter in this case.