SQL para científicos de datos en 100 consultas

Un tutorial de SQL de una sola página, construido en torno a 100 consultas de ejemplo, está siendo elogiado como una introducción clara y práctica a las bases de datos relacionales, útil no solo para aspirantes a científicos de datos sino también para ingenieros de software. Los comentaristas destacan recursos de aprendizaje complementarios, señalan matices técnicos como las uniones no equitativas, la sintaxis específica de SQLite y la semántica de los outer joins, y sugieren que entornos interactivos o conjuntos de datos más grandes reflejarían mejor el trabajo analítico real. El hilo también plantea preguntas más amplias sobre qué significa hoy “científico de datos” en la industria y cómo herramientas como los ORM y los grandes modelos de lenguaje están reconfigurando la forma en que la gente aprende y escribe SQL.

Recepción general del tutorial

  • Ampliamente elogiado como una guía de SQL concisa y basada en ejemplos, adecuada como introducción o repaso, y lo bastante densa como para igualar o sustituir un curso semestral en muchos casos de uso.
  • Algunos sostienen que es un tutorial genérico de SQL/SQLite más que específicamente “para científicos de datos”.
  • Los resultados de aprendizaje (joins, funciones de ventana, transacciones, triggers, JSON, acceso a bases de datos desde Python/ORMs) se ven como un sólido plan de estudios introductorio.
  • Los diagramas en las secciones de “comprueba tu comprensión” dividen opiniones: a algunos les parecen geniales, otros los encuentran confusos.

Semántica, corrección y portabilidad de SQL

  • Varias observaciones técnicas y correcciones:
    • Las tablas temporales, por lo general, están acotadas a la conexión, no necesariamente en memoria.
    • La definición de los left outer joins basada solo en “conservar todas las filas de la izquierda, completar las columnas de la derecha con NULL” se considera incompleta; hay que mencionar la duplicación de filas cuando existen múltiples coincidencias.
    • Se equiparan incorrectamente full outer joins y cross joins; son distintos.
    • Algunas consultas dependen de funciones específicas de SQLite (por ejemplo, FILTER en agregados, reglas de comillas), así que no todos los ejemplos son portables a MySQL/SQL Server/Oracle.
  • Debate sobre ClickHouse: algunos critican su falta de características más amplias del estándar SQL; otros responden que ninguna base de datos cumple por completo y destacan los joins, anti-joins, UDFs, etc. de ClickHouse.
  • Las uniones de series temporales / por desigualdad reciben atención; en algunos sistemas se describen como non-equi joins o joins “ASOF”.

Recursos de aprendizaje y herramientas de práctica

  • Se mencionan muchos tutoriales y sitios de práctica alternativos: SQLZoo, el tutorial de SQL de Mode, StrataScratch, varios cursos tipo “misterio SQL” / basados en historias, y otros recursos de una sola página o basados en notebooks sobre distintos lenguajes/tecnologías.
  • Se valora la base de datos descargable del tutorial (penguins.db); algunos piden más fuentes de datos de práctica y consultas interactivas.
  • Se comparte una app de macOS que permite ejecutar SQL sobre CSV importados como herramienta práctica de aprendizaje.

LLMs y SQL

  • Varios comentaristas informan de un gran éxito usando ChatGPT/LLMs para:
    • Generar consultas complejas a partir de especificaciones en lenguaje natural.
    • Refactorizar o explicar consultas muy largas y desordenadas.
    • Manejar transformaciones de JSON complicadas.
  • Otros se muestran escépticos, prefiriendo SQL de nivel “profesional de bases de datos” frente a consultas de estilo “científico de datos”, y una persona sugiere despectivamente “usa ChatGPT” en lugar de aprender.

Debate sobre la etiqueta “científico de datos”

  • Discusión secundaria prolongada sobre qué significa “científico de datos” hoy en día:
    • Algunos recuerdan expectativas anteriores: fuertes habilidades cuantitativas y de ingeniería de software (por ejemplo, poder implementar modelos de deep learning).
    • Otros sostienen que el término siempre ha sido difuso, solapándose con estadístico, analista, ML engineer y data engineer.
    • Muchos señalan la dilución del título mediante bootcamps y el rebranding de roles de analista como “data science”.
    • Se proponen varias taxonomías que distinguen científicos de datos, ML engineers, data engineers y analistas por niveles de programación, matemáticas y conocimiento del dominio.
    • Algunos insisten en que los científicos de datos deberían ser muy fuertes en SQL; otros observan que, en grandes organizaciones, las responsabilidades ahora se dividen entre roles más especializados.