How structured data really works — tables, keys, JOINs, normalization and ACID — then prove it in a live in-browser SQL sandbox against a fake hacker-alias database. Nothing leaves your machine.
A database stores information in tables. Each table is a grid: columns define what kind of data is stored, rows are individual records, and a primary key uniquely identifies each row. Click any header, row, or the key column below to inspect it.
| id PK | alias | country | threat |
|---|
A vertical field with one type of value — e.g. every value in country is a country code. Schemas define a type per column (text, integer, date…).
One complete record — a single operative with all their attributes. Also called a tuple.
A column whose value is unique for every row, so any record can be addressed exactly. Often an auto-incrementing id.
A question you ask the database in SQL. SELECT alias FROM operatives means “give me the alias column from the operatives table.” Try it in the sandbox below.
Real data is split across tables to avoid repetition. A foreign key (here operatives.crew_id) points at another table's primary key (crews.id). A JOIN stitches them back together. Pick a concept to light up the schema:
A transaction groups statements so they all succeed or all roll back. The guarantees are ACID:
The planner rewrites your query and picks how to execute it. An index turns an O(n) full table scan into an O(log n) lookup. Filter early, select only needed columns, and avoid functions on indexed columns in WHERE.
Run EXPLAIN before a query to see the strategy — Seq Scan (slow, reads everything) vs Index Scan (fast). Try EXPLAIN SELECT * FROM operatives WHERE id = 3 in the sandbox.
Supports SELECT · WHERE · JOIN · GROUP BY · ORDER BY · LIMIT · subqueries · COUNT/AVG/SUM/MIN/MAX · LIKE · IN · EXPLAIN. Cross-links: base converter · how bits work.