That's it for this module and I want to conclude it with a wrap up and the first important thing in this
wrap up is that I reiterate how you should think about data modeling and structuring.
Consider the format in which you'll fetch your data,
how does your application or your data scientists,
how do they need the data?
You want to store your data in a way that it's easy to fetch especially if you're building an app or
if you're having a use case where you fetch a lot because that's the next important question,
how often do you fetch data and how often do you change it?
Do you need to optimize for writes or for reads? Often it's for reads but it could be different
for you. If you write your data a lot,
you should definitely avoid duplicates,
make sure you got no duplicates,
if you read a lot, maybe some duplicates are ok if these duplicates don't change that often,
basically what I covered when walking three different relations setup options.
Also keep in mind how much data will you save and how big is it,
do you store all citizens of New York City? Maybe embedding the data is not your best choice then. How
is your data related in general, one-to-one, one-to-many, many-to-many?
This often gives an indication for whether you want to go with embedded documents or references and
in general, will duplicates hurt you,
do you update your data a lot in which you have to update a lot of duplicates,
do you maybe have snapshot data like with orders and products where you don't care about updates to
the most recent data to your products data.
And finally, will you hit any data or storage limits, like do you need to embed 100 levels deep which is
the limit
mongodb imposes? It's not very likely but that is something you should at least be aware of and which
you should keep in mind. With that, here's the general summary. In this module,
we had a detailed look at how you model schemas, that this can make sense even though mongodb does
not enforce a schema onto you because your application typically needs data in a specific structure.
Important factors are the factors I just mentioned, frequency, relations, size and so on.
You also learned about data types there by the way, text, integers, long integers, decimals and I will also come
back to the numbers later in this course.
We also had a detailed look at relations in this module,
you basically have two options, embedding or references and you want to use embedded documents
if you've got a one-to-one or one-to-many relationship
and if it makes sense for your app and the way you interact with your data with all the points I highlighted
throughout this module and a few seconds ago. References makes sense for many-to-many relationships
or if you want to fetch data separated or if you got very large amounts of nested data, like New York
City with all its citizens. Exceptions are always possible and there is no hard rule,
like many-to-many should always use references as you saw with the example of products and orders but
keeping an eye on your app requirements and how your app works and interacts with your data gives you
a good clue and indication of how you want to structure your data
typically. Last but not least in this module, we had a look at schema validation which allows you to enforce
a certain set of rules on incoming data so that no invalid data ends up in your database.
You learned how you can define such rules and how that works with
json schema
and you also learned that you can configure how your rules are applied,
if actions get blocked or if they just get a warning logged to the log files. This is it for this module
and with that you hopefully got a good understanding of how you have to think about structuring data
and how you can then implement your structure, relate your documents and validate incoming data.