4 ms·

Not strictly germane to the article, but as code SQL has things precisely backwards IMHO. Consider: - DML is declarative; actually, though, I prefer to think o

Not strictly germane to the article, but as code SQL has things precisely backwards IMHO. Consider: - DML is declarative; actually, though, I prefer to think of my query (or update) in terms of a pipeline splicing tuples together, filtering etc, and I'd be happier if I could write it as such, i.e. in a more imperative style (to express intent I mean - the planner should still be free to do all sorts of clever shenanigans, as now) - DDL, otoh, is imperative: "add this index", "remove this column". But here I want a declarative style! i.e. "I would like my table to look like this - make it so". A lot of the aggravation with database maintenance comes from having to manage a stack of non-idempotent DDL operations in order to wrestle the db into the required shape.

glogla 5y ago
I think it's a bit more nuanced - while I would say SELECT is declarative, UPDATE or INSERT or DELETE feel pretty imperative to me. Not only are they literally orders, but only DELETE is idempotent. But for analytics systems, you can get close to having declarative, idempotent DDL by doing CREATE OR REPLACE VIEW ... SELECT for derived data. Some systems even allow transactional and this idempotent DROP TABLE IF EXISTS; CREATE TABLE ... AS SELECT. This doesn't in any way help with indexes, with tables that are primary storage and you can't just drop and recreate them and so on, so there definitely is something missing.