🗄️ SQL & Databases
Learn to store and query data like professionals do. You'll design simple tables, write SELECT queries with joins, and understand what a relational database rea
What you’ll learn
- Why Databases ExistTrace structured data from ledgers and punched cards to Codd's relational model and standardized SQL.Rows-and-columns record keeping predates computers; Hollerith mechanized it for the 1890 census, and Codd's 1970 relational model let machines answer content-based questions over plain tables. SQL, born at IBM in 1974 and standardized in 1986, remains the lingua franca.
- Tables, Rows, ColumnsDefine tables, rows, columns, schemas, and NULL, with fluency across their synonyms.A table is a set of same-shaped records: columns are named, typed facts; rows are complete records — one card per record, as the punch-card era literally practiced. The schema is the enduring blueprint, and NULL marks absent values with famously tricky semantics.
- Keys and RelationshipsChoose sound primary keys and use foreign keys to relate tables without duplicating facts.A primary key is a unique, non-null, never-changing identity — usually a generated id, since names and emails fail the stability test. Foreign keys reference those ids across tables, storing each fact once and connecting the schema into a web.
- SELECT: Asking QuestionsWrite basic SELECT queries with column lists, FROM, ORDER BY, and LIMIT.SELECT declares the answer's shape — which columns, from which table, sorted and capped how — and the engine plans the retrieval. Designed at IBM San Jose to read like structured English, the skeleton SELECT…FROM…ORDER BY…LIMIT underlies every read query you'll ever write.
- Filtering with WHEREFilter rows with WHERE using comparisons, AND/OR logic, and LIKE patterns.WHERE tests every row against a boolean condition; only survivors reach the result. Comparisons, AND/OR combinations, and LIKE wildcards cover most needs — and the same one-row-in-a-million lookup runs at every barcode scan in every store.
- Sorting and AggregatingSummarize data with COUNT/SUM/AVG, GROUP BY buckets, and HAVING filters.Aggregates collapse detail rows into summaries, GROUP BY chooses the buckets, and HAVING filters the buckets after WHERE has filtered the rows. Every dashboard bar chart and inventory report is a GROUP BY wearing a suit.
- JOINs: Combining TablesCombine tables with INNER and LEFT joins and predict which rows survive each.JOIN matches rows across tables by key: INNER keeps matched pairs, LEFT also keeps unmatched left-table rows NULL-padded — the tool for 'customers who never ordered.' It automates the cross-referencing librarians once did drawer by drawer.
- Changing Data SafelyUse INSERT/UPDATE/DELETE with disciplined WHERE previews, and wrap related writes in ACID transactions.Writes obey the WHERE you give them — including the catastrophic no-WHERE case, so preview with SELECT first. Transactions make related changes atomic (BEGIN/COMMIT/ROLLBACK), and ACID's guarantees — atomicity, consistency, isolation, durability — are why critical records live in relational databases.
- Designing Good TablesApply basic normalization and choose correct data types.Store each fact exactly once — splitting repeated details into their own keyed tables prevents update anomalies. Types are enforced promises: DECIMAL for money, real date types for dates. Schema decisions are cheapest on day one and pay rent forever.
- The Database WorldSurvey production databases, indexes, SQLite's ubiquity, and the honest SQL-vs-NoSQL trade-offs.Production systems run PostgreSQL/MySQL-class servers kept fast by indexes — card catalogs for tables — while SQLite embeds full SQL in billions of phones and browsers. NoSQL systems trade relational guarantees for scale or flexibility; most applications still rightly start relational.
Questions this course answers
E.F. Codd's 1970 breakthrough was proposing that data be:
The relational model separates what you ask from how it's fetched — the engine finds the path. That's why 50-year-old queries still run.
SQL's original name, SEQUEL, stood for:
Chamberlin and Boyce designed it at IBM in 1974 to read like structured English; a trademark dispute shortened the name to SQL.
In a relational table, one row represents:
A row (record, tuple) is one complete entry — one book, one customer. Columns are the named, typed facts every row must have.
NULL in a column means:
NULL is the marker for absent information. It is not 0 or '', and it never equals anything — even another NULL.
Which makes the best primary key for a customers table?
A key must be unique, never null, and never change. Names collide and change; emails change; a meaningless generated id promises nothing but identity — which is exactly the job.
A foreign key is:
Foreign keys connect tables: orders.customer_id points at customers.id, so each fact is stored once and referenced everywhere.
Grounded in trusted sources
- E.F. Codd — A Relational Model of Data for Large Shared Data Banks, CACM (1970)
- Donald Chamberlin & Raymond Boyce — SEQUEL: A Structured English Query Language (1974)
- C.J. Date — An Introduction to Database Systems (8th ed., 2003)
- Alan Beaulieu — Learning SQL (3rd ed., O'Reilly, 2020)
- SQLite.org — Most Widely Deployed Database engine documentation
- IBM Archives — System R and the birth of SQL
Every Wunder lesson is built from real, reputable sources — never invented.
Related Science courses
Wunder is a personalized learn-anything platform — tell it any topic and it builds a beautiful, fact-checked course in minutes, with narration, a knowledge check, and a college-style University track.
Browse more Science courses · All topics · Home
© 2026 Wunder Learning LLC · Terms & Privacy