In this lesson, let's talk about the Importance of Schema Design. With MngoDB, you have a lot of flexibility. On one hand, you can throw it totally unrelated things in the same collection. You can insert a insurance policy, a movie description and news article, all into the exact same collection. However, this is unlikely to be a good design and may make finding information or grouping at little bit challenging. On the other hand, you can make your data look very strict and relational where every document has the exact same and only the exact same fields as every other one. In real life, data tends to be somewhere in between these two extremes. Often times you'll have similar characteristics, but also slight differences. And this is why MongoDB has a flexible schema that allows you to store real life data. As it is been said by a few people before me, if you don't have a schema, you should look harder. And this is because whether your schema is explicit or not, you still have one. Now, it is important to consider your schema when you design your database. And this is because you might want to group similar things together or you might want to query for similar objects together. Moreover, you might want to try to identify common characteristics among your documents through aggregation. So currently your schema might not be very explicit. But we strongly recommend that you do think about your schema and make it more explicit. This will make your life a lot better down the road. So what does a schema consist of and how do we make a good schema? Well in the relational world, we generally think about our data first and we think about the relationships among that data when we're designing a schema. But in the MongoDB or in the NoSQL world, there's this now new emphasis on performance when it comes to schema design. And because of this, rather than focusing on data and relationships, we focus on data access patterns and queries. With MongoDB, it's important to think about what data you're going to the query for. And in turn, that will help you design your schema. With MongoDB, you get the flexibility of making your schema however you want. Rather with the relational world, your data and its relationship ultimately dictate your schema. Since we're focusing on performance and access patterns. This means it's going to be important for you to identify which queries you care about having the most performance and which queries you're going to be running the most frequently. After you've identified these queries, you can then start to think about entity relationships between your data. For example, you can have a 1 to N relationship. For example, we have a movie where a movie has many different actors. However, the statement can also be modelled in an N to N relationship type of way. And this because while a movie can have many actors, one actor can have many movies. And ultimately whether you want a schema like this or a schema like this is going to depend on how you're querying your database and what answers you're trying to get. Similar to the flexibility MongoDB gives you when designing your schema, you have the same flexibility with regards to validating your schema. On one end, you can start entering documents without any validation into your MongoDB database. However, you can also create schema validators that allow you to validate the structure and schema of a document before it's actually inserted into the database. With the release of MongoDB 3.6, you're now able to have complete schema validation through JSON schemas. So in the end, it's really a balance. With MongoDB, you can have strict schemas or very loose schemas. But in a MongoDB world, people are generally more concerned about the performance of their queries. And therefore, their schema will be dictated by those queries. After you've figured out what your creator will look like, you can then start considering relationships in your data. Which is the opposite of how we would do schema design in a relational world. But it's also very important to realize that schemas change over time. And this is because the queries you make to your database and your requirements of your projects change over time as well. And so therefore, your schemas change over time. And fortunately for you, MongoDB makes it very, very easy to change your schema.
