Hoje eu me deparei com uma pessoa que perguntava sobre uma ferramenta para ajudar a escrever consultas SQL graficamente. Estava quase respondendo o cara quando lembrei que um dia eu já fui assim.
O primeiro banco de dados relacional com qual eu já trabalhei foi o Access 2.0. Sim senhores, eu já fiz isso, há muito tempo atrás. E havia uma coisa que eu gostava muito nele que era uma ferramenta gráfica para construir consultas. Você arrastava as tabelas lá, depois os campos e ia colocando propriedades aqui e ali. Eu realmente gostava daquilo, parecia tudo mais simples para mim. 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. Ele não entendia o que eu queria 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 o Oracle ignorou por motivos pra lá de obscuros no SQL*Plus. 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, recortar, colar, copiar e mover se torna muito mais rápido do que arrastar as coisas com o mouse. Também passei rapidamente a fazer coisas mais complexas e eficientes também. O lema do SQL é dizer “WHAT NOT HOW”. Cada consulta SQL antigamente 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 um 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 você segue em geral:
- Escrevo o FROM e digo quais tabelas vão fazer parte da minha consulta, qua 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 outras cláusulas, sempre revisando as três etapas anteriores.
E vejam como a arquitetura do seu banco de dados começa a ser uma preocupação:
- Quando escrevo o FROM, penso no tamanho das tabelas e as ligações (JOINs) entre elas;
- Quando escrevo o WHERE, penso nos índices existentes nas tabelas e 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!
