Redundant Data Storage
NoSQL stores many to many relationships in the same way that de-normalized tables do – by storing them redundantly. Since you do not base your NoSQL design on relationships between data, you database design is driven by the type queries that will run against it.
You would use the same design methodology here that you would use to denormalize a relational database: if query performance is of utmost importance, you would flatten (de-normalize) your database – to accommodate the query in question.
This optimizes your tables for one type of query at the expense of other types of queries. If your application has the need for both types of queries to be equally optimized, you would be better off not de-normalizing and not NoSQL ing it.
Integrity Violation with DeNormalized Data
There is a risk with denormalization – that data (or entire sets of data) will get out of sync with one another. This is called an integrity violation or a data anomaly. A normalized relational database (RDBMS) is DESIGNED to prevent such integrity violations.
How does NoSQL PREVENT integrity violations?
In a denormalized database and in NoSQL, it becomes the programmer’s responsibility to write application code to prevent integrity violations.