- [Instructor] Before we create the data structures
for our order management, let's review
the design behind it first.
For that, I created
an entity relationship diagram, short ERD.
So it shows the entities that will later be in the database.
A order is represented first by an order ID,
that's just one unique ID.
Then we want to store the user ID.
That's the ID of the user in MongoDB, the email address,
and an order should also have a status like shipped.
You might now wonder why we even store the email address
as we already store the user ID.
This is because the user might be deleted
from MongoDB at some point, and then we would have no way
to reach out to the user again.
Of course, for a real order management
you would also want to store the address of the user.
So, each order also consists of items to be ordered.
And those items will now be stored
in a separate table called OrderItem.
And this OrderItem is connected to the order
via the ID of the order.
This is why the OrderItem has a column orderId.
And the relationship between those two tables is a 1 to N.
So, 1 order has N, so multiple order items.
In an OrderItem, we store the sku,
so that's the item number,
we store the quantity of the item that should be ordered,
we store the name of the item enterprise.
Again, you might wonder why we don't just store the sku
and this should identify the item anyways.
This is again, because items might at some point
be deleted from the catalog,
but we want to still have accurate information
in our order management, maybe to run statistics on it.
In the next video, we will transform this database design
into a model for Sequelize.