NoSQL Data Modeling Patterns

Relational Data Model relies on normalization for some reason. Storing data in tables, and then having to do complex database level queries and joins in order to get the data in the format we need for the user-read is annoying when you’re database is super normalized. This is called impedance mismatch.

Common No-SQL Data Patterns:

1. Embedded Pattern: Allows you to keep all information relevant to a specific data type within the same document.
2. Aggregate Pattern: Used to store attributes of a larger embedded (or separate) collection within a document for quicker access and reads.

MongoDB Data Modelling Best Practices:

• Rule 1: Favor embedding unless there is a compelling reason not to.
• Rule 2: Needing to access an object on its own is a compelling reason not to embed it.
• Rule 3: Avoid joins and lookups if possible, but don’t be afraid if they can provide a better schema design.
• Rule 4: Arrays should not grow without bound. If there are more than a couple of hundred documents on the many side, don’t embed them; if there are more than a few thousand documents on the many side, don’t use an array of ObjectID references. High-cardinality arrays are a compelling reason not to embed.
• Rule 5: As always, with MongoDB, how you model your data depends entirely on your particular application’s data access patterns. You want to structure your data to match the ways that your application queries and updates it.