Half a century of SQL

Learning and Teaching SQL

• Several commenters say SQL is hard to start with because you need realistic data and problems; toy tutorials stay too simple.
• SQLite and browser-based/Postgres playgrounds are praised as low-friction ways to learn, especially when bundled with guided exercises and shared databases.
• Others argue it’s “not that hard”: abundant data dumps (e.g., Stack Overflow), CSVs, and built‑in SQLite/DuckDB make experimentation easy.
• A recurring point: SQL practice needs real, slightly boring business questions (aggregations, exclusions, edge cases), which beginners don’t invent on their own.

Declarative Mindset vs Imperative Background

• Many note the mental shift from imperative to declarative set‑oriented thinking is the main barrier.
• Using subqueries and especially CTEs is highlighted as making query structure more readable, composable, and debuggable.
• Advice: if you find yourself looping over rows, you’re probably misusing SQL.

Alternatives, DSLs, and Dataframe APIs

• KQL, Malloy, PRQL, Polars, Ibis, dplyr, and others are cited as more elegant or composable for analytics, often compiling to SQL.
• Reasons they don’t “take off”: limited backend support, extra learning/setup, lack of write/update support, immaturity, and the huge installed base of SQL knowledge.
• Some prefer SQL over Pandas for complex OLAP because SQL is a language, not a library, and its composability (subqueries, GROUP BY) feels cleaner.

Critiques of SQL vs Defenses

• Criticisms: non‑modular, context‑dependent features; awkward syntax; hard to reason about advanced queries; bug‑prone joins; stagnation in DDL constraints; perceived failure of the original “just declare what you want” vision.
• Defenses: SQL is “good enough,” ubiquitous, highly expressive, and consistent across decades and vendors; optimizers are powerful when queries are written relationally; worst SQL arises from imperative thinking.
• Some see SQL, C, and JavaScript as “good enough” incumbents that are too entrenched to replace without overwhelming benefits.

Constraints, DDL, and Integrity

• Complaints about decades‑old constraint sets (PK, FK, UNIQUE, CHECK) and desire for richer, more expressive, yet performant invariants (non‑unique FKs, NOT‑EXISTS constraints).
• Others note many modern systems don’t even enforce PK/FK at scale, and complex constraints can be prohibitively expensive.
• Triggers are seen as powerful but inferior to declarative constraints for stating and reasoning about invariants.

SQL in the Application Stack

• Some want tighter integration: DB schema in source control, easier testing, and type‑safe query DSLs (e.g., jOOQ‑style).
• Others argue for doing more logic inside the database (constraints, views, triggers, stored procedures), sometimes even collapsing the “application tier,” though experiences here are mixed, especially on larger teams.