Detailed explanation
DDL, DML, DQL, DCL and TCL are common categories used to explain SQL statements by their purpose: defining structures, changing data, reading data, controlling access and managing transactions. These categories help you distinguish what a statement affects and how to use it safely. They are useful interview terminology, although classifications are not completely uniform: some documentation includes SELECT under DML rather than treating DQL as a separate category.
DDL means Data Definition Language. CREATE, ALTER and DROP create, modify or remove database objects such as tables; TRUNCATE removes all rows while retaining the table definition and is commonly classified as DDL. For example, ALTER TABLE users ADD phone VARCHAR(15); changes the table schema rather than updating existing phone values. The database updates its metadata and, depending on the operation and engine, may also reorganise stored data or acquire restrictive locks. Do not assume every DDL statement automatically commits: transactional behaviour differs across database systems.
DML means Data Manipulation Language. INSERT adds rows, UPDATE changes existing rows and DELETE removes rows. UPDATE users SET phone = '99999' WHERE id = 1; changes only matching rows; without WHERE, it targets every row. DQL means Data Query Language and usually refers to SELECT, which retrieves data using filtering, joins, grouping and sorting. Under the hood, the database parses and validates a query, chooses an execution plan and reads the required data. SELECT does not normally change stored rows, but it can still consume substantial resources or acquire locks depending on the query and database.
DCL means Data Control Language. GRANT and REVOKE manage privileges; for example, GRANT SELECT ON users TO analyst; permits reading that table, subject to database-specific syntax and security rules. TCL means Transaction Control Language. COMMIT makes transaction changes permanent, ROLLBACK undoes uncommitted changes, and SAVEPOINT marks a position for partial rollback. ROLLBACK TO SAVEPOINT sp1; requires an existing savepoint in the current transaction. Interviewers generally expect correct expansions, representative commands and practical distinctions, especially schema versus data changes and rollback limits under autocommit.
Key points to remember
- DDL defines database structures: CREATE, ALTER, DROP and TRUNCATE.
- DML changes table data: INSERT, UPDATE and DELETE.
- DQL retrieves data using SELECT; some classifications include SELECT within DML.
- DCL controls access through privileges: GRANT and REVOKE.
- TCL manages transaction boundaries and rollback points: COMMIT, ROLLBACK and SAVEPOINT.
Common mistakes candidates make
- Claiming that DDL always auto-commits or that TRUNCATE can never be rolled back, regardless of the database.
- Confusing DELETE, which removes rows, with DROP, which removes the table itself.
- Assuming ROLLBACK can undo already committed changes or return to a savepoint that was never created.
Likely follow-up questions
What is the difference between DELETE, TRUNCATE and DROP?
DELETE removes rows and supports a WHERE clause; TRUNCATE removes all rows without a WHERE clause while retaining the table definition. DROP removes the table itself, including its data and definition. Locking, identity-reset and rollback behaviour depend on the database.
What is the difference between COMMIT, ROLLBACK and SAVEPOINT?
COMMIT finalises the current transaction, whereas a full ROLLBACK discards its uncommitted changes. SAVEPOINT creates a named position inside a transaction so you can undo later changes without discarding all earlier work.
Can an UPDATE always be rolled back?
No; rollback requires the change to remain uncommitted and the storage system to support transactions. With autocommit enabled, a successful standalone UPDATE is normally committed automatically, so use an explicit transaction when you need control over committing or rolling back.
Interview tip: Explain each abbreviation with its purpose and one command, then demonstrate the difference between changing a table's schema and updating its rows.