Why Relational Databases Still Run the World
And what every real data engineer should deeply understand before writing a single JOIN.
.👋 Welcome to Week 4 of Zero2DataEngineer
This week we leave behind raw querying and step into schema thinking.
This is where you stop being a query-runner and start becoming a real engineer.
Here’s what we’ll cover:
How relational databases actually work
The power of constraints and keys
When to choose OLTP vs OLAP
How broken schema design breaks pipelines
And how to crush RDBMS interview questions
What Even Is a Relational Database?
It’s a system that stores data in tables — with clearly defined relationships between them.
Think:
usersordersproductspayments
Each table is connected using primary and foreign keys, ensuring data consistency, referential integrity, and scalable querying.
Real Example: Food Delivery App
You’re building for DoorDash, Swiggy, or Zomato.
Here’s your schema:
users(user_id, name, location)restaurants(restaurant_id, name, cuisine)orders(order_id, user_id, restaurant_id, created_at)order_items(order_item_id, order_id, item_name, price)
Now someone deletes a restaurant record.
If you didn’t use foreign key constraints, your orders table is now pointing to... nothing.
Your BI dashboard breaks. Refunds misfire. Customers rage tweet.
This is why RDBMS still matters — it protects you from yourself.
Schema Mistakes I’ve Lived Through
Mistake #1: I once stored prices in 3 different places — product table, invoice table, and analytics table.
Marketing ran a 10% off promo.
One table got updated. Two didn’t.
Revenue numbers were off. Refunds had to be manually processed. Chaos.Fix: I created a normalized schema where pricing logic sat in one place, and every other table referenced it via foreign key. Revenue dashboards started matching Stripe. Everyone slept better.