Data Definition Language builds the shape of your database. Design a table column by column, watch the CREATE TABLE statement write itself, then ALTER, TRUNCATE and DROP it to see what happens to the data each time.
DDL (Data Definition Language) creates and changes the structures that hold data. Common commands include CREATE to define an object, ALTER to change it, and DROP to remove it. The exact syntax and supported operations depend on the database engine.
This creates the table and declares rules on its rows. A schema is a contract shared by every query and application that uses it, so changes should be deliberate and versioned.
DELETE FROM products removes rows while retaining the table definition; it can use a WHERE clause and is usually DML. DROP TABLE products removes the table definition and its data. TRUNCATE is a separate command in engines that support it and has different transactional and identity behavior. SQLite does not support TRUNCATE TABLE.
In a production system, record each schema change as a migration that can be applied in a known order. Consider existing data, locks, validation cost, application compatibility, and rollback strategy. Adding a non-null column to a populated table may require a default or a staged rollout. DDL transaction behavior varies by engine and statement; do not assume every operation can be rolled back.
Use constraints to keep the database responsible for valid states; see SQL constraints. For row changes rather than schema changes, see DML.
For a change shared by a running application, one safe pattern is to add a compatible nullable column, deploy code that can read both old and new forms, backfill data in controlled batches, then add stricter rules and remove obsolete fields in a later migration. This avoids requiring every application instance to change at the same instant. The right steps depend on the engine's locking and DDL behavior. Test migration time and rollback or forward-repair plans against production-scale data.
A migration should have a clear precondition and postcondition: which schema version it expects, what objects it changes, and how the application behaves before and after deployment. Keep migrations in version control and apply them consistently to every environment. Avoid editing a previously applied migration because two databases may then claim the same version while having different schemas. For a risky change, write a forward repair plan as well as a rollback plan; some data transformations cannot be reversed after information is discarded.
About to run: press TRUNCATE. Before it does — what happens to the readout?
Committing to an answer first is the point — the reveal runs the experiment on the visualisation above and reads the real value back, so nothing here is scripted.
Say the answer out loud before you reveal it — recalling it is what makes it stick, and rereading it is not.
What does this module say about “The schema-changing statements”?
What does this module say about “DROP is not DELETE”?
What does this module say about “Treat schema changes as migrations”?
Create, alter and drop tables with DDL, and see how constraints — NOT NULL, UNIQUE, FOREIGN KEY — enforce data quality at the edge.