If we take as example a table with a single row:
In imperative (SQL):
INSERT INTO TABLE1 (name, wage) VALUES ('John','50k');
Then one day John gets a raise:
UPDATE TABLE TABLE1 SET wage = '60k' where name = 'John'
In declarative (pseudo code in yaml):
- table: TABLE1 - name: John wage: 50k
Then one day John gets a raise:
- table: TABLE1
- name: John
wage: 60kYou state what you want, yes - but you are forced to articulate it as a specific set of table navigations / logistics through the relational model, as if you were writing the implementation. Then, however, the database then may choose ignore those and do something else to resolve the data you asked for if it wants, if it can prove the outcome is equivalent.
For example I want all the ice creams bought by John. Even though the schema knows the foreign key relationship between "user" and "purchase" I have to tell it back to the database engine in my query. But even after doing that there's no requirement the database will actually implement the steps I was forced so ungraciously to specify. It may "optimise" them away and do something else.
In C, you’d have to program how the data should be stored (data structure) and written to disk.
Just like declaring the columns you're specifying values for and then the values for them?
If SQL was declarative, you wouldn't have an error on duplicate CREATE, there would be no CREATE OR REPLACE, and changing column types would not be an error. It would just 'table x should be like this, make it so'.
(Actual queries/projections I would say are declarative, just the nomenclature pretends they're not. (Select from join all sounds very imperative, but really you're just describing what you want, and have no say over how it's retrieved.))