Database Fundamentals: Tables, Keys, SQL & Design That Lasts

Why this course exists

Every app you use — banking, booking, streaming — is a pretty face on a database. Yet most developers learn databases backwards: copy-pasted SQL, mysterious errors, and schemas that rot within months. This guide (and our full course) builds the foundations in the right order, so every database you touch for the next decade makes sense.

The ideas that matter most

• What a database is — the vault-and-librarian model: one truth, guarded access, crash safety.
• Tables, rows, schema — one table per kind of thing, types enforced at the door, NULL means unknown.
• Keys — primary keys identify, foreign keys connect. Stable surrogate ids beat meaningful values that change.
• Relationships — one-to-one, one-to-many, many-to-many via junction tables. FK always sits on the many side.
• Normalization — 1NF/2NF/3NF: every fact stored once, so updates can't contradict themselves.
• SQL basics — SELECT, WHERE, ORDER BY, LIMIT. Filter in the database, not in your code.
• JOINs & aggregations — stitch split tables back together; GROUP BY turns millions of rows into answers.
• Indexes — sorted shortcuts that turn minute-long scans into millisecond seeks (at a write cost).
• Transactions & ACID — multi-step writes as one unbreakable unit. Money moves atomically or not at all.
• ER diagrams — sketch boxes and lines before CREATE TABLE. Argue on the whiteboard, not in a 2 AM migration.

A sane learning order

Follow the course order — it's deliberate: concepts (what-is-a-database → relational-model) → identity & links (keys → relationships) → clean design (normalization → er-diagrams) → asking questions (sql-basics → sql-joins) → speed & safety (indexes → transactions-acid).

Start here: Database Fundamentals course.

Mistakes beginners make

• Linking by name instead of id. Names change; ids don't. Every "order history lost after rename" bug starts here.
• SELECT * in app code. Fetches unread columns across the network and breaks silently on schema change.
• INNER JOIN by default. It drops orphans silently — "customers with zero orders" vanish instead of showing 0.
• One giant flat table. Feels fast on day one; becomes uneditable contradiction-soup by month three. Normalize first, denormalize consciously later.

FAQ

SQL or NoSQL for my first database? SQL (Postgres). The relational model teaches thinking in structure, constraints, and relationships — skills that transfer everywhere, including to NoSQL later.

Do I need to memorize normal forms? No — internalize the rule: every fact stored once, with its owner. The 1NF/2NF/3NF labels just name the violations you'll learn to smell.

Why are JOINs slow sometimes? Missing indexes on foreign keys, usually. A JOIN is a lookup per row — without an index each lookup scans. Index what you join on.

When do transactions matter? Whenever two or more writes must succeed together — transfers, bookings, stock decrements. Single-row writes are atomic already; multi-step operations need wrapping.