SQL for data scientists in 100 queries

Original Article ↗ Hacker News Discussion ↗

A single-page SQL tutorial built around 100 example queries is being praised as a clear, practical introduction to relational databases—useful not only for aspiring data scientists but for software engineers as well. Commenters highlight complementary learning resources, point out technical nuances such as non‑equi joins, SQLite-specific syntax, and outer join semantics, and suggest that interactive environments or larger datasets would better reflect real-world analytics work. The thread also surfaces broader questions about what “data scientist” now means in industry and how tools like ORMs and large language models are reshaping how people learn and write SQL.

Overall reception of the tutorial

  • Widely praised as a concise, example-driven SQL guide, suitable as an intro or refresher, and dense enough to match or replace a semester-long course for many use cases.
  • Some argue it’s a generic SQL/SQLite tutorial rather than specifically “for data scientists.”
  • Learning outcomes (joins, window functions, transactions, triggers, JSON, DB access from Python/ORMs) are seen as a strong introductory curriculum.
  • Diagrams in the “check your understanding” sections are polarizing: some find them great, others confusing.

SQL semantics, correctness, and portability

  • Several technical nits and corrections:
    • Temporary tables are generally connection-scoped, not necessarily in-memory.
    • Definition of left outer joins based only on “keep all left rows, fill right columns or NULL” is seen as incomplete; must mention row duplication when multiple matches exist.
    • Full outer joins vs cross joins are incorrectly equated; they are distinct.
    • Some queries rely on SQLite-specific features (e.g., FILTER on aggregates, quoting rules), so not all examples are portable to MySQL/SQL Server/Oracle.
  • Debate over ClickHouse: some criticize its lack of broader SQL standard features; others counter that no DB is fully compliant and highlight ClickHouse joins, anti-joins, UDFs, etc.
  • Time-series / inequality joins get attention; described as non-equi joins or “ASOF” joins in some systems.

Learning resources and practice tools

  • Many alternative tutorials and practice sites are mentioned: SQLZoo, Mode’s SQL tutorial, StrataScratch, various “SQL mystery” / story-based courses, and other language/tech single-page or notebook-based resources.
  • The tutorial’s downloadable DB (penguins.db) is appreciated; some ask for more practice data sources and interactive queries.
  • A macOS app that lets users run SQL over imported CSVs is shared as a hands-on learning tool.

LLMs and SQL

  • Multiple commenters report strong success using ChatGPT/LLMs to:
    • Generate complex queries from plain-English specs.
    • Refactor or explain very long, messy queries.
    • Handle tricky JSON transformations.
  • Others are skeptical, preferring “database professional”-level SQL over “data scientist-style” queries, and one person dismissively suggests “just use ChatGPT” instead of learning.

Debate over the “data scientist” label

  • Extended side discussion on what “data scientist” means today:
    • Some recall earlier expectations: strong quantitative plus strong software engineering skills (e.g., able to implement deep learning models).
    • Others argue the term has always been fuzzy, overlapping with statistician, analyst, ML engineer, and data engineer.
    • Many note dilution of the title via bootcamps and the rebranding of analyst roles as “data science.”
    • Several taxonomies are proposed distinguishing data scientists, ML engineers, data engineers, and analysts by coding, math, and domain-expertise levels.
    • Some insist data scientists should be very strong in SQL; others note that in large organizations, responsibilities are now split across more specialized roles.