We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Database Types Storage
Free preview: the first 2 parts of this 8-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Database Types Storage
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
You're building a product catalog. Simple, right? Product name, price, description, throw it in a table.
Then reality hits. A laptop has RAM, CPU, screen size, and GPU specs. A T-shirt has size, color, material, and fit type. A book has author, ISBN, page count, and genre. A piece of furniture has dimensions, weight, and assembly instructions.
Every product type has completely different attributes. In a relational database, you have ugly choices:
None of these are good. They're all fighting the fundamental mismatch between rigid tabular schemas and data that's inherently varied and nested.
Document stores said: "What if the database just stored your data the way your application already thinks about it, as JSON objects with nested fields that vary per record?"
A document store holds collections of documents. Each document is a self-contained JSON-like object (technically BSON in MongoDB's case. Binary JSON with extra types).
Here's a product document:
{
"_id": "prod_laptop_001",
"name": "MacBook Pro 16-inch",
"price": 2499,
"category": "laptops",
"specs": {
"cpu": "M3 Max",
"ram_gb": 36,
"storage_gb": 1000,
"screen_inches": 16.2,
"gpu": "38-core GPU"
},
"reviews": [
{ "user": "alice", "rating": 5, "text": "Beast of a machine" },
{ "user": "bob", "rating": 4, "text": "Great but expensive" }
],
"variants": [
{ "sku": "MBP16-36-1TB", "color": "Space Black", "in_stock": true },
{ "sku": "MBP16-36-2TB", "color": "Silver", "in_stock": false }
]
}
Notice what's happening here. The specs are nested. Reviews are an array of objects. Variants are another array. In a relational database, this would be four separate tables with foreign keys. In a document store, it's one document, self-contained, denormalized, and fetched in a single read.