🔤SQL keywords

Keywords are the grammar, not the data

Reserved words (SELECT, FROM, WHERE, …) tell the parser which clause you are in. Identifiers (table and column names you choose) live in a different namespace, until you collide with a reserved word, then you must quote the identifier, and portability drops fast.

🧭Three practical rules for naming

Most keyword pain disappears if you adopt boring, explicit names.

Prefer snake_case nouns

patient_id, assay_run, well_layout read well in logs and avoid the worst offenders (user, order, group) that fight every ORM.

Quote only when trapped

PostgreSQL double-quotes preserve case; MySQL uses backticks. Quoted names are easy to mistype in psql or migration scripts, treat them as technical debt with an owner.

Fully qualify in migrations

core.patients survives search_path surprises in CI and prod. Flyway/Liquibase scripts should never rely on implicit default schemas.

🗂️How keywords cluster in real workloads

Scan this when reading unfamiliar SQL, each cluster hints at the clause shape coming next.

Cluster	Keywords (sample)	What you are building
Query shape	SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT / OFFSET / FETCH	A read pipeline: source rows → filter → bucket → filter buckets → project → sort → slice.
Joins	INNER, LEFT, RIGHT, FULL, OUTER, JOIN, ON, USING, CROSS	Compose two relations with a predicate; outer joins add NULL padding rules.
Set ops	UNION, UNION ALL, INTERSECT, EXCEPT	Vertical stacking of compatible column bags, dedup only when you truly mean it.
DML	INSERT, UPDATE, DELETE, INTO, VALUES, SET	Row mutations governed by constraints and transaction boundaries.
DDL	CREATE, ALTER, DROP, TABLE, INDEX, VIEW	Shape how truth is stored, usually stronger locks and migration discipline than DML.

Table named order, column named key

Every query needs noisy quoting: INSERT INTO "order" …. ORMs generate different escape strategies per dialect, reviews get slower and grepping breaks.

Rename + document

Rename to purchase_order / sort_key (or domain-specific). Add a CI check that fails DDL introducing reserved identifiers without an explicit waiver comment.

SQL

Keywords in action

SELECT order_id, customer_id
FROM orders
WHERE status IN ('PAID', 'SHIPPED')
ORDER BY order_id DESC
LIMIT 5;

✓Illustrative result set

order_id	customer_id
9005	441
9004	220
9003	118
9002	441
9001	332

Memorization shortcut

You do not need to memorize every vendor extension keyword. Do memorize the logical order of the core SELECT pipeline (see the SQL syntax lesson): almost every debugging story flows from there.

TL;DR

Keywords gate parsing: you cannot use them as bare column names without quoting. Portability pain usually comes from dialect extensions (LIMIT vs TOP/OFFSET FETCH, ILIKE vs case-insensitive collations). Prefer a style guide for uppercase/lowercase keywords, but prioritize understanding clause order over trivia lists.