Today we will continue using Mongoose and Mongo to build our database. Building schemas is creating rules of a collection so that we could access documents with ease since their structure are consitent. As our app grows, we would have many collections. Some are isolated and some are relating to others. Any DBMS will give us many options create these connections and also methods access data through them.
Our database could be like a temple, skyscrapper or a labyrinth ... each will serve different purposes ; has pros and cons. Somnetimes this art form called database architecture.
Every ecommerce websites are different. Some allow user to have as many shopping cart at once as the user want. Some only allow 1 cart at a time however still keeping the history of all previous cart. We will focus on the later one. To store infomation of a cart , we need either a "field" (Embedded) or a new related "schema" (References). Before choosing which methods we want to go with let's discuss. In your group answer these questions.
Questions :
The key decision in designing data models for MongoDB applications revolves around the structure of documents and how the application represents relationships between data. MongoDB allows related data to be embedded within a single document.
Embedded documents capture relationships between data by storing related data in a single document structure. MongoDB documents make it possible to embed document structures in a field or array within a document. These denormalized data models allow applications to retrieve and manipulate related data in a single database operation. For many use cases in MongoDB, the denormalized data model is optimal.
Here is an example of 1 user info storing cart info as one of it's field
{
_id:
name: ,
age: ,
email: ,
password: ,
job: ,
cart: [
{
_id: ,
status: ,
productList: [
{
_id: ,
name: ,
qty: ,
price: ,
},
{
_id: ,
name: ,
qty: ,
price: ,
},
{
_id: ,
name: ,
qty: ,
price: ,
}
, {
_id: ,
name: ,
qty: ,
price: ,
}
]
},
{
_id: ,
status: ,
productList: [
{
_id: ,
name: ,
qty: ,
price: ,
},
{
_id: ,
name: ,
qty: ,
price: ,
},
{
_id: ,
name: ,
qty: ,
price: ,
}
, {
_id: ,
name: ,
qty: ,
price: ,
}
]
},
{
_id: ,
status: ,
productList: [
{
_id: ,
name: ,
qty: ,
price: ,
},
{
_id: ,
name: ,
qty: ,
price: ,
},
{
_id: ,
name: ,
qty: ,
price: ,
}
, {
_id: ,
name: ,
qty: ,
price: ,
}
]
},
{
_id: ,
status: ,
productList: [
{
_id: ,
name: ,
qty: ,
price: ,
},
{
_id: ,
name: ,
qty: ,
price: ,
},
{
_id: ,
name: ,
qty: ,
price: ,
}
, {
_id: ,
name: ,
qty: ,
price: ,
}
]
},
}
Pros | Cons |
Let's say want a route to get the user info and all his shopping history (carts), this process would be so easy by simply connect to | If we just want to get the |
In case product name change, or price change, or even deleted. History of the user's cart will not be affected | But if we want the product info to be updated, we must find every changes product in every cart of every users to update it |
Delete a user, will also delete all the shopping cart at ease | As a shop owner , checking the performance (sale) of shop would be inacurate. |
Everything we design a database, no matter what method of modelling we choose we must ask our selves :
References store the relationships between data by including links or references from one document to another. Applications can resolve these references to access the related data. Broadly, these are normalized data models.
Data model using references to link documents. Both the contact document and the access document contain a reference to the user document. See Normalized Data Models for the strengths and weaknesses of using references.
Here is an example of referencing data. This approach take 3 schemas and reference them with each other _id
Given 2 products
{
_id : "product 1",
name: ,
price: ,
}
{
_id : "product 2",
name: ,
price: ,
}
{
_id: "tuan_id",
name:
email:
password:
role:
}
{
_id: "Haha Cart",
OWNER: "tuan_id"
status: ,
productList: [
{productId: "product 1",qty: },
{productId: "product 2",qty: }
]
}
Pros | Cons |
Embeded'cons | Embeded'pros |
There is no magic fomular for a perfect data modelling. The answer is alway "depend" on what feature we decided for our application, commonly called business logic. Backend coding syntax is difficult, but the logic behind connecting data toghether to have the best way possible to solve a set of problems is what make us programmer.
Today we will start the CoderComm backend project. For the next few days we will re-create the API that we have been using for our previous React front-end application. We will be collaborating on this repo