We are about to make the most important feature of an Ecommerce website, the Shopping Cart endpoints. This will be one of our most challenging topic of our course , so we will walkthrough this together in 2 days.
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.
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 :
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 :
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.
Assume that user could only one active cart at a time. Assume we are making free api for newbs front-end dev/learners at codding school. Meaning that we will do all the heavy lifting ( calculation) in backend. eg. calculate the total of cart.
Use References method to:
Remake the back end and add Rating feature