SQL para cientistas de dados em 100 consultas
Um tutorial de SQL em uma única página, estruturado em torno de 100 consultas de exemplo, está sendo elogiado como uma introdução clara e prática a bancos de dados relacionais — útil não apenas para aspirantes a cientistas de dados, mas também para engenheiros de software. Os comentaristas destacam recursos complementares de aprendizagem, apontam nuances técnicas como joins non-equi, sintaxe específica do SQLite e a semântica de outer joins, e sugerem que ambientes interativos ou conjuntos de dados maiores refletiriam melhor o trabalho analítico do mundo real. O debate também levanta questões mais amplas sobre o que “cientista de dados” significa hoje na indústria e como ferramentas como ORMs e modelos de linguagem grandes estão mudando a forma como as pessoas aprendem e escrevem SQL.
Recepção geral do tutorial
- Amplamente elogiado como um guia SQL conciso, guiado por exemplos, adequado como introdução ou revisão, e suficientemente denso para equivaler ou substituir um curso de um semestre em muitos casos de uso.
- Alguns argumentam que é um tutorial genérico de SQL/SQLite, em vez de especificamente “para cientistas de dados”.
- Os resultados de aprendizagem (joins, funções de janela, transações, triggers, JSON, acesso ao banco a partir de Python/ORMs) são vistos como um currículo introdutório sólido.
- Os diagramas nas seções “verifique sua compreensão” dividem opiniões: alguns os acham ótimos, outros confusos.
Semântica, correção e portabilidade de SQL
- Vários detalhes técnicos e correções:
- Tabelas temporárias geralmente são escopadas à conexão, não necessariamente em memória.
- A definição de left outer joins baseada apenas em “manter todas as linhas da esquerda, preencher colunas da direita com NULL” é vista como incompleta; é preciso mencionar a duplicação de linhas quando há múltiplas correspondências.
- Full outer joins e cross joins são erroneamente equiparados; são distintos.
- Algumas consultas dependem de recursos específicos do SQLite (por exemplo,
FILTERem agregações, regras de aspas), então nem todos os exemplos são portáveis para MySQL/SQL Server/Oracle.
- Debate sobre ClickHouse: alguns criticam a falta de recursos mais amplos do padrão SQL; outros contrapõem que nenhum banco é totalmente conforme e destacam joins, anti-joins, UDFs etc. do ClickHouse.
- Joins de séries temporais / desigualdade recebem atenção; são descritos como non-equi joins ou joins “ASOF” em alguns sistemas.
Recursos de aprendizagem e ferramentas de prática
- Muitos tutoriais alternativos e sites de prática são mencionados: SQLZoo, o tutorial de SQL do Mode, StrataScratch, vários cursos baseados em “SQL mystery”/história e outros recursos de página única ou baseados em notebooks para linguagem/tecnologia.
- O banco de dados baixável do tutorial (
penguins.db) é apreciado; alguns pedem mais fontes de dados para prática e consultas interativas. - Um app para macOS que permite executar SQL sobre CSVs importados é compartilhado como ferramenta prática de aprendizado.
LLMs e SQL
- Vários comentaristas relatam grande sucesso usando ChatGPT/LLMs para:
- Gerar consultas complexas a partir de especificações em linguagem natural.
- Refatorar ou explicar consultas muito longas e confusas.
- Lidar com transformações JSON complicadas.
- Outros são céticos, preferindo SQL de nível “profissional de banco de dados” em vez de consultas “no estilo cientista de dados”, e uma pessoa sugere desdenhosamente “é só usar ChatGPT” em vez de aprender.
Debate sobre o rótulo “cientista de dados”
- Discussão paralela extensa sobre o que “cientista de dados” significa hoje:
- Alguns lembram expectativas anteriores: forte conhecimento quantitativo e forte engenharia de software (por exemplo, ser capaz de implementar modelos de deep learning).
- Outros argumentam que o termo sempre foi vago, sobrepondo-se a estatístico, analista, engenheiro de ML e engenheiro de dados.
- Muitos observam a diluição do título por bootcamps e a reclassificação de funções de analista como “data science”.
- Várias taxonomias são propostas, distinguindo cientistas de dados, engenheiros de ML, engenheiros de dados e analistas por níveis de programação, matemática e conhecimento de domínio.
- Alguns insistem que cientistas de dados devem ser muito bons em SQL; outros observam que, em grandes organizações, as responsabilidades agora estão divididas entre funções mais especializadas.