
### Introduction

There are many things to consider when picking a schema like is our app read or write heavy , what data are frequently accessed together , performance consideration and how our dataset grow and scale.

In this post we will look at the common methodologies we can use when designing database schema for our application.There are two types of approaches(relational and non relational) when designing a schema.

Lets first look at how relational database design compares to MongoDB schema design.

### Schema Design Approaches - Relational vs. MongoDB

When it comes to MongoDB database schema design, this is what most developers think of when they are looking at designing a relational schema and a MongoDB schema.

![Same Picture](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/most_devs_meme_555911448f.png)

And this is how that makes me feel.

![Nooooo](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/nooooo_5e8b190db4.gif)

#### Relational Schema Design

When designing a relational schema, typically, devs model their schema independent of queries, then by using prescribed approaches, they will normalize (typically in 3rd normal form). The tl;dr of normalization is to split up your data into tables, so we don't duplicate data. Let's take a look at an example of we you would model some user data in a relational database.

![Relational](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/relational_user_model_4c3c6a05cd.png)

In this example, you can see that the user data is split into separate tables and it can be JOINED together using foreign keys in the user_id column of the Professions and Cars table. Now, let's take a look at how we might model this same data in MongoDB.

#### MongoDB Schema Design

Now, MongoDB schema design works a lot differently than relational schema design. With MongoDB schema design, there is:

- No formal process
- No algorithms
- No rules

![No Rules](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/no_rules_fb55daf6d0.gif)

When you are designing your MongoDB schema design, the only thing that matters is that you design a schema that will work well for your application. Two different apps that use the same exact data might have very different schemas if the applications are used differently. When designing a schema, we want to take into consideration the following:

- Store the data
- Provide good query performance
- Require reasonable amount of hardware

Let's take a look at how we might model the relational User model in MongoDB.

```json
{
  "first_name": "Paul",
  "surname": "Miller",
  "cell": "447557505611",
  "city": "London",
  "location": [45.123, 47.232],
  "profession": ["banking", "finance", "trader"],
  "cars": [
    {
      "model": "Bentley",
      "year": 1973
    },
    {
      "model": "Rolls Royce",
      "year": 1965
    }
  ]
}
```

We can see that instead of splitting our data up into separate collections or documents, we take advantage of MongoDB's document based design to embed data into arrays and objects within the User object. Now we can make one simple query to pull all that data together for our application.

#### Types of Relationships between data

- One to One

One field can only have one value.Like movie &rarr; name (A movie can only have one name)

- One to Many

Here we have 3 types of one to many relationships and they are :

&rarr; 1 : Few (One movie can win few awards)

&rarr; 1 : Many (A movie can have hundreds and thousands of reviews)

&rarr; 1 : Ton (A movie app can have tons of logs)

- Many to Many

One movie can have many actors , but one actor can also play in many movies.

#### Referencing vs Embedding

MongoDB schema design actually comes down to only two choices for every piece of data. We can either embed that data directly or reference another piece of data using the $lookup operator (similar to a JOIN)

##### Referenced / Normalized

**movie**

```json
{
"_id": ObjectID('222'),
"title":"Oblivion",
"releaseYear":2013,
"actors": [ObjectID('555'),ObjectID('777')]
}
```

**actor**

```json
{
    "_id": ObjectID('555'),
    "name":"Tom Cruise",
    "age":59,
    "born":"New York,US"
}
```

```json
{
    "_id": ObjectID('777'),
    "name":"Andrea Riseborough",
    "age":40,
    "born":"Newcastle,UK"
}
```

**Pros** : Performance - _Its easier to query each documant on its own._

**Cons** : _We need 2 queries to get data from referenced document._

##### Embedded / Denormalized

```json
{
"_id": ObjectID('222'),
"title":"Oblivion",
"releaseYear":2013,
"actors":[
{
    "_id": ObjectID('555'),
    "name":"Tom Cruise",
    "age":59,
    "born":"New York,US"
},
{
    "_id": ObjectID('777'),
    "name":"Andrea Riseborough",
    "age":40,
    "born":"Newcastle,UK"
}]
}
```

**Pros** : Performance - _We can get all the information in one query._

**Cons** : _Impossible to query the embedded document on its own._

#### When to embed and when to reference

|                      | Embedding                       | Referencing                                            |
| -------------------- | ------------------------------- | ------------------------------------------------------ |
| Relationship Type    | 1:Few , 1:Many                  | 1:Many , 1:Ton , Many:Many                             |
| Data Access Patterns | High read/white ratio           | Low read/write ratio                                   |
| Data closeness       | Datasets really belong together | We frequently need to query both datasets on their own |

#### Types of Referencing

- **Child Referencing (1:Few)**

**movie**

```json
{
"_id": ObjectID('222'),
"title":"Oblivion",
"releaseYear":2013,
"actors": [ObjectID('555'),ObjectID('777')]
}
```

**actor**

```json
{
    "_id": ObjectID('555'),
    "name":"Tom Cruise",
    "age":59,
    "born":"New York,US"
}
```

```json
{
    "_id": ObjectID('777'),
    "name":"Andrea Riseborough",
    "age":40,
    "born":"Newcastle,UK"
}
```

- **Parent Referencing (1:Many , 1:Ton)**

```json
{
    "_id": ObjectID('23'),
    "app":"My Movie DB"
}
```

```json
{
    "_id":ObjectID('1'),
    "app":ObjectID('23'),
    "type" :"error",
    "timestamp": 1412844672
}
```

```json
{
    "_id":ObjectID('2'),
    "app":ObjectID('23'),
    "type" :"success",
    "timestamp": 1412844672
}
```

- **Two Way Referencing (Many:Many)**

**movie**

```json
{
    "_id": ObjectID('222'),
    "title":"Oblivion",
    "releaseYear":2013,
    "actors": [
        ObjectID('555'),
        // ... any many more
    ]
}
```

```json
{
    "_id": ObjectID('555'),
    "name":"Tom Cruise",
    "age":59,
    "born":"New York,US",
    "movies":[
        ObjectID('222'),
        // ... any many more
    ]
}
```

**Rules**

- Favor embedding unless there is a compelling reason not to.
- Needing to access an object on its own is a compelling reason not to embed it.
- Avoid joins/lookups if possible, but don't be afraid if they can provide a better schema design.
- Arrays should not grow without bound.

_References_ :

- [MongoDB Schema Design Best Practices](https://www.mongodb.com/developer/article/mongodb-schema-design-best-practices/)
- Node.js, Express, MongoDB Bootcamp : Jonas
