SQL = papel & tinta

Hoje eu me deparei com uma pessoa que perguntava sobre uma ferramenta para ajudar a escrever consultas SQL graficamente. Estava quase respondendo quando lembrei que um dia eu já fui assim.

O primeiro banco de dados relacional com o qual já trabalhei foi o Access 2.0. Sim, senhores, eu já fiz isso, muito tempo atrás. E havia uma funcionalidade nele que eu gostava muito: era uma ferramenta gráfica para construir consultas. Você arrastava as tabelas lá, depois os campos e, então, ia colocando propriedades aqui e ali. Eu realmente gostava daquilo, parecia tudo mais simples. Usar SQL puro me parecia muito complexo e desnecessário. Mas as minhas consultas foram ficando mais complexas com o tempo. E eu comecei a brigar com o Access, que não entendia o que eu queria fazer ou não tinha opções suficientes.

Quando eu comecei a trabalhar com PostgreSQL, eu portei meus primeiros sistemas do Access para ele e tive que escrever minhas consultas em SQL. Mas o PostgreSQL tem o psql, um cliente em modo texto simples, mas muito poderoso. Ele herda a tradição do shell do Unix de utilizar uma biblioteca conhecida como readline, coisa que a Oracle ignorou no SQL*Plus por motivos para lá de obscuros. Uma vez que você se acostuma com o readline no shell, passa a imaginar que toda a linha de comando deveria ser assim. E pode ser. O PostgreSQL e o MySQL usam, e funciona muito bem.

O fato é que, em pouco tempo, eu passei a escrever SQL bem mais rápido do que eu fazia minhas consultas no Access. Com um bom editor de texto, ações como recortar, colar, copiar e mover se tornam muito mais rápidas do que arrastar as coisas com o mouse. Também passei rapidamente a fazer coisas mais complexas e eficientes. O lema do SQL é dizer “WHAT NOT HOW”. Antigamente, cada consulta SQL significava todo um programa escrito só para realizar aquela operação. Hoje, o otimizador de consultas executa este programa dinamicamente para você. Mas você ainda tem que aprender a comunicar o que quer para o banco de dados. Escrever e estruturar o raciocínio ainda é um exercício de escrita. Saber escrever é tão importante quanto conhecer algoritmos. No caso do SQL, você não se preocupa mais com o HOW, apenas com o WHAT. Claro que tive que estudar também. Recomendo sempre os livros do Joe Celko para quem quer e deve ir além. Alguns clássicos nunca morrem.

Quando você aprende a escrever SQL de forma organizada, passa a entender melhor como o banco de dados funciona. Existe uma linha de raciocínio que eu sigo em geral:

Escrevo o FROM e digo quais tabelas vão fazer parte da minha consulta, qual a origem das informações envolvidas;
Depois escrevo o WHERE e digo quais registros dessas tabelas deverão ser retornados;
Após o SELECT, digo quais campos vão aparecer no resultado;
Somente depois coloco coisas como GROUP BY, HAVING, LIMIT e outras cláusulas, sempre revisando as três etapas anteriores.

E veja como a arquitetura do banco de dados começa a ser uma preocupação:

Quando escrevo o FROM, penso no tamanho das tabelas e nas ligações (JOINs) entre elas;
Quando escrevo o WHERE, penso nos índices existentes nas tabelas e na seletividade dos dados que estou trazendo;
Quando escrevo o SELECT, penso na apresentação dos dados para a aplicação, se preciso formatar, calcular ou agrupar alguns dados.

Esse tipo de preocupação faz toda a diferença, não apenas para o DBA, mas para o programador também. Não sou radicalmente contra o uso de ferramentas de ORM, nem de bancos NoSQL, mas aprender SQL ainda é um exercício importante de lógica e de arquitetura da sua aplicação. Portanto, pegue papel & tinta ou seu melhor editor de textos e mãos à obra!