Most beginners think “database” just means “a place to store data.” But a real relational database is designed to handle way more than that, correctness, consistency, and efficient querying at scale.
Why not just save data anywhere?
When you use a proper SQL database, you get:
- ACID properties (Atomicity, Consistency, Isolation, Durability): you don’t want to half-update a payment or lose data after a crash.
- Joins: data in the real world is related. Users have orders, orders have products, etc. You can join tables instead of duplicating data everywhere.
- Indexes: searching without indexes is like scanning every page of a book to find a word. With indexes (B-Tree or others), you get faster lookups.
- Data integrity: foreign keys, constraints, and types prevent accidental or corrupt data.
Normalization vs Denormalization
- Normalization reduces duplication and enforces data consistency. You split data into multiple tables and relate them through keys.
- Denormalization (often used for performance or analytics) duplicates data intentionally to avoid heavy joins.
Don’t just copy blog diagrams. Ask: Does my data really need to be fully normalized? How will I query it most often? These choices affect both correctness and performance.
ORM vs Manual Queries
- ORM (Object-Relational Mapping): abstracts SQL into code objects. Faster to get started, easier migrations, but can hide what's really happening under the hood.
- Manual SQL: gives you full control. You see exactly how joins and conditions work, and can fine-tune performance.
Beginners often think ORM is always “better”, it isn't. It depends on your project, team skill, and performance constraints.
How to design healthy data models
- Understand your access patterns first. What queries will run most? Where are the bottlenecks likely to appear?
- Choose keys carefully (avoid wide composite primary keys if you don’t need them).
- Use constraints (unique, foreign keys) to keep your data correct.
- Think about indexes from day one, adding them later when you already have millions of rows can be painful.
Your challenge this week:
Go beyond “I just save data somewhere.” Design a small relational schema for a fake app (a simple marketplace), sketch out relationships, and try writing actual SQL joins instead of only relying on your ORM.
Next week: Git Beyond Push: Real Version Control
Top comments (0)