• You know how newbies are convinced that DRI can be handled by the app?  They are ALWAYS proved to be wrong.  Every single time.
    Its hard enough getting Data Quality right in a disciplined data repository such as an RDBMS.  In MongoDB what you persist has to be a valid JSON document.  That's it.  You can stick your granny's fruit cake recipe in the middle of records from a flight recorder and as far as the DB is concerned that is perfectly OK.
    The use case for MongoDB is when you have a rapidly evolving schema or something that requires a highly flexible schema such as a SurveyMonkey type application and possibly product catalogue management.
    Most of us will never see the loads and data volumes that caused the excitement for NOSQL in the first place.  I don't work for Facebook or Netflix or a company requiring high frequency trading.
    The value in NOSQL is that it has forced us to revisit assumptions and identify weaknesses that need to be addressed.
    1.  How do we provide full text search capabilities that are genuinely useful?
    2.  How should we handle log data?
    3. How should we handle transient data such as web sessions
    4. How should we handle queueing
    5. How should we handle and traverse flexible relationships where the relationship itself is as valuable as the data items participating in those relationships?
    When you use different technologies to solve your problems you mustn't lose sight of the fact that your solution creates its own problems (integration for example).  The problems you create may be bigger than the problems you solve