Data Manipulation Language changes what is in your tables. Run INSERT, UPDATE and DELETE against a live table, watch every affected row light up, and use a transaction to undo the damage.
Four verbs do almost all the work in day-to-day SQL. Two of them can ruin your afternoon if you forget a WHERE clause.
Data Manipulation Language covers the statements that read and change rows: INSERT, UPDATE, DELETE and SELECT. Where DDL defines the container, DML fills and reshapes its contents.
UPDATE employees SET salary = 0; is perfectly valid SQL. Without a WHERE, it applies to every row in the table. The same is true of DELETE FROM employees;.
Set the filter to "all rows" in this lab and watch the affected-row counter jump to the full table size. The professional habit is to run the equivalent SELECT first, confirm the row count is what you expected, and only then convert it to an UPDATE or DELETE.
Unlike DDL, DML is transactional. Wrap your changes in a transaction and nothing is permanent until you say so:
BEGIN; UPDATE employees SET salary = salary * 1.1 WHERE dept = 'Engineering'; -- check the result ROLLBACK; -- or COMMIT;
Press BEGIN in this lab, delete some rows, then press ROLLBACK — they all come back. This is the single most valuable habit when running a statement you are not completely sure about.
Transactions also provide atomicity: if you debit one account and credit another, either both happen or neither does. A crash between the two statements cannot leave money missing.
DML is where data actually changes, and the WHERE clause is what stands between a targeted fix and a table-wide accident. Preview with SELECT, wrap risky work in a transaction, and let the constraints you declared in DDL catch what you miss.
Data Manipulation Language changes what is in your tables. Run INSERT, UPDATE and DELETE against a live table, watch every affected row light up, and use a transaction to undo the damage.