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.
Before a single row can be stored, something has to declare what a row looks like. That is DDL's job.
Data Definition Language is the subset of SQL that creates and changes structure — tables, columns, types, constraints, indexes. It is distinct from DML, which changes the contents. A useful shorthand: DDL is the blueprint, DML is the furniture.
In most engines (MySQL and Oracle in particular) DDL statements perform an implicit commit: the moment you run one, any open transaction is committed and the change is permanent. A ROLLBACK afterwards will not save you. PostgreSQL is the notable exception — it supports transactional DDL.
This is why DROP TABLE on the wrong connection is one of the most feared mistakes in this profession. Press the DROP button here and note that the row counter goes to zero with no undo offered.
Constraints declared in DDL are checked on every write, forever, no matter which application is connecting:
Putting a rule here rather than in application code means it cannot be bypassed by a script, a migration or a careless intern with a database client.
DDL defines the contract your data must obey. Time spent choosing sensible types and constraints up front is repaid every day afterwards — and because these statements are usually irreversible, they deserve more care than any query you will write.
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.