Antes de Consultar o Banco, Questione o Problema

A consulta que já contém uma resposta

E se muitos erros de software não começassem no código, mas na pergunta feita ao banco de dados?

Essa hipótese parece técnica, porém revela um problema muito mais amplo. Quando alguém escreve uma consulta, não está apenas pedindo informações. Está declarando o que considera relevante, quais categorias aceita como reais e quais relações acredita existirem. Uma consulta mal formulada pode retornar resultados perfeitamente corretos e, ainda assim, responder à pergunta errada.

É por isso que depurar sistemas e investigar problemas humanos exigem a mesma disciplina intelectual: examinar as suposições antes de otimizar a solução. No Laravel, por exemplo, uma consulta pode ser expressa de maneira elegante e legível com o construtor de consultas. Mas nenhuma API consegue corrigir uma definição equivocada do problema. Se o sistema procura pedidos atrasados quando a causa real está no fornecimento de peças, uma consulta mais rápida apenas produzirá uma resposta errada com maior eficiência.

A conexão importante é esta: consultar é uma forma de questionar a realidade. O código transforma uma hipótese em um filtro. O banco devolve evidências condicionadas por esse filtro. Pensar bem, portanto, exige tanto saber construir consultas quanto saber desconfiar delas.

A maior ameaça não é não encontrar dados. É encontrar exatamente os dados que confirmam uma pergunta mal formulada.

O filtro invisível por trás de toda resposta

Considere uma aplicação que precisa mostrar os clientes que não compraram nos últimos noventa dias. A implementação inicial pode parecer simples:

$clientes = DB::table('clientes')
    ->whereNotExists(function ($query) {
        $query->select(DB::raw(1))
            ->from('pedidos')
            ->whereColumn('pedidos.cliente_id', 'clientes.id')
            ->where('pedidos.created_at', '>=', now()->subDays(90));
    })
    ->get();

A consulta pode estar tecnicamente correta. Ainda assim, ela repousa sobre várias suposições escondidas:

1. Todo relacionamento relevante entre cliente e empresa passa pela tabela de pedidos.
2. Uma compra nos últimos noventa dias significa atividade recente.
3. A data de criação do pedido é a melhor medida de comportamento.
4. Cancelamentos, devoluções e pedidos incompletos devem contar como compras.
5. Clientes sem pedidos são comparáveis a clientes antigos que deixaram de comprar.

Essas suposições não aparecem como comentários no código. Elas estão incorporadas nos nomes das tabelas, nos filtros e nas colunas escolhidas. O resultado final parecerá objetivo porque foi produzido por uma máquina, mas a objetividade é apenas aparente. O banco não sabe o que significa cliente ativo. Ele apenas executa a definição que recebeu.

Esse é o ponto em que a prática de questionar suposições se torna uma ferramenta de engenharia. Antes de alterar o código, precisamos perguntar: qual decisão será tomada com base nesse resultado? A equipe quer recuperar clientes? Identificar risco de abandono? Medir o valor da carteira? Cada objetivo exige uma definição diferente de atividade.

Para recuperar clientes, talvez um comprador recente seja alguém que concluiu uma compra. Para detectar abandono, talvez seja necessário comparar o intervalo habitual entre compras de cada pessoa. Para medir a carteira, talvez o critério deva considerar receita, margem e recorrência. A mesma tabela pode sustentar várias consultas legítimas, mas elas respondem a perguntas diferentes.

A primeira lição é simples e difícil: não existe consulta neutra. Toda consulta é uma teoria compactada em sintaxe.

Os cinco porquês aplicados ao código

A técnica dos cinco porquês costuma ser apresentada como uma maneira de investigar falhas operacionais. O mesmo método pode ser usado para examinar uma funcionalidade aparentemente banal.

Imagine o pedido: “Crie uma tela com todos os usuários inativos”. Em vez de começar com um where, faça a investigação.

Por quê? Porque a equipe quer enviar uma campanha de reativação.

Por quê? Porque acredita que usuários inativos têm maior probabilidade de abandonar o produto.

Por quê? Porque a frequência de login caiu no último mês.

Por quê? Porque uma alteração recente dificultou o acesso em dispositivos móveis.

Por quê? Porque o fluxo de autenticação passou a exigir uma etapa que falha em determinada versão do navegador.

A pergunta inicial pedia uma consulta. A investigação encontrou um defeito de produto. Sem os porquês, a equipe poderia gastar semanas segmentando usuários e enviando mensagens para pessoas que não estavam desinteressadas. Elas estavam impedidas de entrar.

Esse exemplo mostra que a causa raiz nem sempre está no lugar em que o sintoma aparece. Um relatório pode mostrar queda de vendas, mas a origem pode estar no estoque. Uma métrica pode apontar menor engajamento, mas a causa pode ser uma falha de usabilidade. Uma fila pode parecer lenta, mas o problema real pode ser uma consulta que traz registros demais porque uma hipótese antiga nunca foi revisada.

No Laravel, a legibilidade do construtor de consultas pode ajudar a tornar essas hipóteses visíveis. Compare uma consulta longa e opaca com uma construção que nomeia cada etapa do raciocínio:

$pedidos = DB::table('pedidos')
    ->join('clientes', 'clientes.id', '=', 'pedidos.cliente_id')
    ->where('pedidos.status', 'concluido')
    ->whereBetween('pedidos.created_at', [$inicio, $fim])
    ->where('clientes.tipo', 'empresa')
    ->select('clientes.id', 'clientes.nome')
    ->selectRaw('SUM(pedidos.total) as receita')
    ->groupBy('clientes.id', 'clientes.nome')
    ->having('receita', '>', 10000)
    ->get();

A forma é clara, mas ainda precisamos perguntar o que cada decisão significa. Por que apenas pedidos concluídos? A receita inclui impostos? O período é baseado na criação ou no pagamento? Empresas e pessoas físicas são realmente comparáveis? O limite de dez mil foi definido por análise ou herdado de um relatório antigo?

Legibilidade não substitui pensamento crítico. Ela apenas cria melhores condições para que o pensamento crítico aconteça. Um código compreensível permite que outras pessoas encontrem as premissas e as contestem. Um código confuso transforma decisões históricas em uma espécie de autoridade invisível.

Quando a eficiência amplifica o erro

Existe uma tentação recorrente em projetos de software: tratar todo problema como um problema de performance. A consulta demora, então adicionamos um índice. A página carrega lentamente, então introduzimos cache. O relatório parece pesado, então reduzimos a quantidade de dados exibidos.

Essas técnicas são importantes, mas podem produzir uma forma perigosa de progresso: o erro fica mais rápido, barato e difícil de perceber.

Imagine uma empresa que calcula o estoque disponível subtraindo todos os pedidos registrados do estoque total. A consulta executa em poucos milissegundos e alimenta milhares de decisões. Depois se descobre que pedidos cancelados continuam sendo contabilizados. O sistema não estava lento. Estava respondendo com precisão a uma regra incorreta.

A diferença entre um problema de execução e um problema de definição pode ser organizada em três camadas:

1. A camada sintática: a consulta é válida e pode ser executada?
2. A camada semântica: os dados selecionados representam o conceito desejado?
3. A camada causal: agir sobre esse resultado resolve a causa do problema?

Muitas equipes verificam apenas a primeira camada. Algumas verificam a segunda, conferindo se os nomes e filtros parecem corretos. As decisões mais importantes exigem a terceira: saber se o resultado tem relação causal com a intervenção planejada.

Se a taxa de conversão caiu, filtrar usuários que não compraram pode revelar um grupo interessante. Mas esse grupo não explica necessariamente a queda. A causa pode ser um preço maior, uma falha no pagamento, uma campanha direcionada ao público errado ou uma alteração no processo de entrega. A consulta encontra correlações. A investigação precisa descobrir mecanismos.

Aqui surge uma distinção fundamental: dados respondem “o que aconteceu”, enquanto perguntas causais tentam descobrir “o que produzirá uma mudança”. Confundir as duas coisas leva a intervenções cosméticas. A equipe observa que usuários que não receberam uma mensagem compraram menos e conclui que a mensagem aumenta vendas. Talvez os usuários tenham sido escolhidos justamente porque já estavam menos engajados.

Questionar suposições não significa rejeitar dados. Significa recusar a ideia de que dados falam sozinhos. Eles falam por meio de categorias, filtros, períodos, junções e critérios que alguém escolheu.

A consulta como experimento pequeno

Uma maneira prática de melhorar decisões é tratar cada consulta como um experimento sobre uma hipótese, não como uma simples extração de registros.

Suponha a hipótese: “Clientes que receberam suporte no último mês têm menor probabilidade de renovar”. Antes de construir o relatório, escreva a hipótese completa. O que significa receber suporte? Um chamado aberto, uma resposta enviada ou um problema resolvido? O que significa renovar? Pagar até a data de vencimento ou permanecer ativo após trinta dias? Quais clientes devem ser excluídos porque entraram recentemente e ainda não tiveram oportunidade de renovar?

Depois, formule hipóteses alternativas:

1. O suporte não reduz a renovação. Clientes com problemas procuram mais suporte.
2. O suporte aumenta a renovação quando o caso é resolvido rapidamente.
3. O tipo de problema importa mais do que o contato com a equipe.
4. A relação desaparece quando se controla o tempo de uso do produto.

A consulta deixa de ser um veredito e passa a ser um instrumento de comparação. Com o construtor de consultas, é possível criar versões diferentes da mesma investigação, alterar filtros e observar como o resultado muda. Esse processo revela a sensibilidade da conclusão: se uma pequena mudança na definição transforma completamente o resultado, a conclusão é frágil e deve ser apresentada com cautela.

Um bom procedimento inclui quatro movimentos:

1. Nomeie as suposições

Escreva o que precisa ser verdadeiro para que a consulta responda à pergunta. Inclua o significado das métricas, a qualidade dos dados, o período analisado e os grupos comparados.

2. Inverta a pergunta

Pergunte: “E se a suposição principal estiver errada?”. Se usuários inativos não estiverem desinteressados, mas bloqueados por um defeito, que evidência apareceria? Se pedidos atrasados forem consequência de falta de material, que tabela ainda não foi consultada?

3. Procure evidências que contrariem a narrativa

Não busque apenas confirmar o resultado esperado. Divida os dados por dispositivo, região, canal, tipo de cliente, etapa do processo ou versão do produto. A segmentação não serve apenas para encontrar oportunidades. Serve para localizar exceções que denunciam uma explicação incompleta.

4. Teste uma intervenção pequena

Se a hipótese é que um fluxo impede a conversão, corrija o fluxo em um grupo limitado e compare os resultados. Se a hipótese é que o estoque de segurança reduzirá atrasos, teste a política em uma categoria antes de aplicá-la a toda a operação.

Essa abordagem une investigação e engenharia. O banco ajuda a observar. O código ajuda a testar. A realidade, por meio dos resultados, ajuda a corrigir a pergunta.

O que uma boa consulta revela sobre uma boa organização

Uma organização madura não é aquela que possui mais painéis, mais métricas ou consultas mais sofisticadas. É aquela que consegue dizer com clareza quais decisões dependem de quais definições.

Quando uma equipe discute se um usuário está ativo, ela não está apenas debatendo uma coluna. Está decidindo como distribuir atenção, orçamento e esforço. Quando define um pedido como atrasado, está determinando quem será responsabilizado. Quando escolhe uma causa raiz, está escolhendo onde investir recursos.

Por isso, consultas importantes deveriam carregar um pequeno contrato intelectual. Esse contrato pode responder a perguntas como:

• Qual decisão este resultado pretende orientar?
• Que definição foi usada e quais alternativas foram rejeitadas?
• Quais dados estão ausentes ou podem estar distorcidos?
• Que evidência faria a equipe mudar de ideia?
• O resultado descreve uma associação ou sustenta uma hipótese causal?

Esse hábito também melhora o software. Consultas nomeadas, filtros explícitos e testes para casos limítrofes tornam as regras do negócio discutíveis. Uma regra discutível pode ser aperfeiçoada. Uma regra escondida em uma sequência de condições tende a sobreviver apenas porque ninguém sabe onde encontrá-la.

O ganho mais importante não é apenas técnico. É cultural. A equipe aprende que discordar de uma definição não significa bloquear o trabalho. Significa proteger o trabalho contra a falsa sensação de certeza.

A pergunta mais valiosa em uma reunião de dados talvez não seja “qual é o número?”, mas “o que precisaria ser verdade para que esse número significasse o que estamos dizendo?”.

Principais aprendizados

• Liste as suposições antes de escrever a consulta. Inclua definições, períodos, relacionamentos entre tabelas e critérios de inclusão.
• Use os cinco porquês para investigar o pedido por trás do pedido. Uma solicitação de relatório pode esconder um defeito de processo, produto ou fornecimento.
• Separe validade técnica de validade semântica. Uma consulta que executa sem erro ainda pode representar mal o conceito analisado.
• Crie hipóteses alternativas e procure evidências contrárias. A melhor consulta não é a que confirma sua narrativa, mas a que permite distinguir narrativas concorrentes.
• Teste mudanças em pequena escala. Use os dados para observar e a intervenção para aprender se a suposta causa realmente produz o efeito esperado.

No fim, escrever uma consulta é escolher uma lente. A lente pode ser nítida, rápida e elegante, mas ainda assim deformar o mundo se seus pressupostos forem ruins. A maturidade está em combinar a habilidade de perguntar ao banco com a coragem de perguntar à própria pergunta.

Talvez o verdadeiro papel de uma boa ferramenta de dados não seja entregar respostas com mais velocidade. Talvez seja tornar visíveis as crenças que antes estavam escondidas dentro das respostas. Quando isso acontece, programar deixa de ser apenas fazer sistemas obedecerem. Torna-se uma prática de investigação: observar, duvidar, testar e reformular até que a solução esteja voltada para o problema real.