DDL & DML: The Two Halves of SQL

Introduction
Working with a database always splits into two separate jobs: building the structure that will hold data, and then actually putting data in, changing it, or reading it. SQL separates these two jobs into two categories of commands — DDL and DML.

What is DDL?

DDL stands for Data Definition Language. These commands define or change the structure of a database — tables, columns, and their types — without touching the actual data inside.

Example — creating a table:

Adding a column to an existing table:

What is DML?
DML stands for Data Manipulation Language. These commands work with the actual data inside the tables inserting, updating, deleting, or retrieving rows.

Example — inserting a row:

Updating a row:

Deleting a row:

Retrieving data:

Key Difference
The distinction that clarified this for me: DDL changes the container, DML changes what's inside the container. Running CREATE TABLE builds an empty structure , no data exists yet. Only after that does INSERT (a DML command) actually put rows into it.

Another important detail: most DDL commands are harder to undo. DROP TABLE deletes the table and everything in it, structure included — there's no "undo" in most database systems once it's committed. DML changes like DELETE or UPDATE are often reversible if wrapped in a transaction, but DDL is generally treated as a bigger, more permanent action.

What I Learned
Understanding that DDL commands run first, and rarely change once a table is in use, helped me realize why planning a table's structure carefully upfront (column types, primary keys) matters — going back to change it later with ALTER is possible, but riskier once real data and other queries already depend on that structure.