[Talk Notes] Introduction to Relational Databases: Learning Normalization You Keep Postponing

I usually speak from slides; this time I tried talk notes and am publishing them.

https://nishinomiya.connpass.com/event/355662/

I hoped generative AI would fill gaps, but it invented things I did not say (😄), so this stays bullet points. Next time I might record audio and use that as input.

Introduction

Think about product lifespan
- Frontend: 2–4 years
- Backend: 3–8 years
- DB: until the service ends
As a frontend developer, I must treat data as the most critical asset
Types of databases
- CSV files (historically)
- Web Storage and SQLite
- RDBs like MySQL and Postgres
- NoSQL like Amazon DynamoDB and Redis
RDB does not mean normalization is mandatory; NoSQL does not forbid it
- Different design philosophies and strengths
- Either can cross into the other's territory depending on the case

Aspect	RDB (MySQL, etc.)	NoSQL (MongoDB, Firestore, etc.)
Data structure	Tables (rows and columns)	JSON-like, key-value, graph, etc.
Design focus	Consistency and normalization	Flexibility and scalability
Common approach	Normalize and JOIN	Denormalize and embed data
JOIN	◎ Fast and optimized	△ or ❌ Some DBs have no JOIN

Benefits of denormalization
- Good performance (no JOIN)
- Single fetch gets everything
- Fits distributed systems
- All data in one place—easier to stop thinking
Drawbacks of denormalization
- More duplicate data
- More places to update on writes
- Harder flexible search and aggregation (nested data)
- Nested data makes schema management harder
Knowing normalization lets you choose denormalization deliberately—that balance matters.

Normalization techniques

(Omitted—many sites explain the forms.)

Normalization vs. computational cost

Famous N+1 problem
JOIN cost is O(M + N)
- SELECT * FROM A JOIN B ON A.id = B.id
- O(M) (build hash) + O(N) (probe)
What matters in a DB: avoid fetching data and avoid making the DB compute
- Read replicas for read-only traffic (do not hit the master)
- Cache (Redis/Memcached, etc.)
- Offload spatial computation to Elastic services
Separate high availability and easy schema changes from computational cost

Closing

Map the real world into data
Points when modeling real-world data in a DB
Practical design tips