appDBMS1-- INSERT: add rows2-- UPDATE: change rows3-- DELETE: remove rowsid name copies1 Dune 22 Coraline 03 Holes 14 The Road 35 Wonder 06 Piranesi 1row+1
Back row: the app that sends the changes and the DBMSFront: the SQL statement, the reply (rows affected) and the books tableEnvelopes: a statement going to the DBMS, the reply coming backAt the back: the library app that sends the changes and the DBMS that carries them out. In front: the app's SQL statement, the DBMS's reply, and the books table. INSERT adds a row (Piranesi). UPDATE tests every row against its WHERE and changes only the matches (Holes, 1 → 2 copies). DELETE removes the rows its WHERE matches (Coraline and Wonder), and the reply counts the rows each statement affected. Without WHERE an UPDATE hits every row; inside BEGIN, ROLLBACK undoes it. Without ORDER BY, SQL does not promise any order for the rows of a result. The figure keeps the rows in id order; the last query asks for that with ORDER BY id.

Adding rows

  1. A SELECT only reads a table; it never changes it. Three SQL commands do change it: INSERT adds new rows, UPDATE changes values in rows, and DELETE removes rows. Here they change a small library’s books table.

Changing values

Removing rows

Undo and check

What happens

;; step 1/11 · change
SELECT   reads rows        (changes nothing)
INSERT   adds new rows
UPDATE   changes values in rows already there
DELETE   removes whole rows

table books, before any change:
  id  name      copies
  1   Dune      2
  2   Coraline  0
  3   Holes     1
  4   The Road  3
  5   Wonder    0

In INSERT 0 1 the 0 is a leftover: it used to be an internal object id and is now always 0. The 1 is the number of rows inserted. psql shows these replies; drivers give you the row count. Without ORDER BY, SQL does not promise any order for the rows of a result. The figure keeps the rows in id order; the last query asks for that with ORDER BY id.