Rob Conery, creator of SubSonic, states his opinion about reporting in NoSQL database: Use the right tool for the right job. Consider splitting up your data in ‘domain-data’ and ‘reporting-data’. The domain-data is kept databases which fits best, like a document-store, object-database etc. The data for the reporting stored separately. So it’s a separation of data concerns.
First you may think: “Oh no, more work”. Two data-stores, that’s even more code, more libraries etc you have to maintain. But I’m not if that is really true. When I’m thinking about all the ‘pain’ you go through to map you domain into a normalized relational model. Especially when the relational-model is used for both, reporting and the application-domain.
For example I’ve once build a quite sophisticated survey application. Well I first designed my domain-model for representing a survey. Like domain-objects for a question, possible-answers, rating-criteria’s etc. I’ve build a nice model an then mapped it onto a relational representation. Now of course a survey-application also needs detailed reports. Well first the domain-model was easy to work with. But it wasn’t optimal for reporting. Things got worse because I tried to ‘hammer’ the reporting-‘nails’ with a ORM-mapper. And it was a nightmare, because the ORM couldn’t handle complex queries appropriately . So I needed to tweak the domain-model to make it more reporting friendly. In summary, I spend a lot of time tweaking and changing the domain-model and ended with something, which was neither good for reporting nor a good domain-model.
When I think back, I could have saved a lot of trouble by separating the both parts completely. Use nice domain-model for the survey, preferably stored in object-database or maybe a document-database. This is data which is actively changed and updated. And then for reporting, additional data is stored In big, flat and denormalized tables.
Conclusion: I can imagine that separating data for different purposes can be a real benefit.
- What Am I Working On?
- (Unexpected Useful) Patterns for Fault Tolerant Software