A coisa que ninguém explica direito sobre contagem duplicada em banco de dados
Você já abriu um painel administrativo, rodou uma query e viu dois números que não faziam sentido. Um tava certo, o outro era o dobro. A diferença era um COUNT com GROUP BY que não considerava campos de unicidade reais. Isso é o problema central quando se fala em how many how many — ou seja, quantas vezes algo conta como diferente versus quantas vezes ele aparece de verdade. Achei que isso fosse bobeira no início do meu trabalho com dados. Até perder três horas num deploy de relatório porque o contador via dua linhas distintas onde na verdade era o mesmo usuário logado de dois aparelhos diferentes. O campo "id_usuario" era único, mas "sessao_id" duplicava. A query simplesmente juntava os dois sem perceber.
o que é actually how many how many
Não existe uma técnica oficial com esse nome. É mais um vira-lata conceitual que surge quando alguém pergunta "quantos registros tem" e depois descobre que a pergunta original era "quantos itens únicos tem". A palavra "how many" se repete porque a ferramenta de consulta ou o relatório está fazendo duas contagens ao mesmo tempo: uma bruta e uma deduplicada, e elas estão misturadas na mesma view sem separação clara. No dia a dia eu vejo isso principalmente em:
- painéis de BI que mostram total de transações e total de clientes em colunas adjacentes, mas usam a mesma tabela sem JOIN adequado
- scripts Python que contam linhas de um DataFrame sem remover duplicatas antes
- queries SQL com COUNT(*) dentro de subconsultas que retornam resultados repetidos por causa de campos de junção não exclusivos
como resolver na prática
A primeira coisa que eu faço é mapear quais campos realmente definem unicidade. Isso não é óbvio. Em sistemas de e-commerce, por exemplo, "pedido_id" parece único, mas um mesmo pedido pode aparecer múltiplas vezes na tabela de itens. Se você faz COUNT(*) na tabela de itens agrupado por pedido, o número sobe artificialmente. O workaround que eu uso agora é simples. Em vez de confiar no COUNT direto da tabela raiz, eu sempre passo por uma CTE (Common Table Expression) com DISTINCT nos campos-chave antes de qualquer agregação. Funciona assim:
WITH unicos AS (SELECT DISTINCT pedido_id, cliente_id FROM pedidos) SELECT COUNT(*) FROM unicos; Isso elimina a duplicação. Mas tem um detalhe importante que muita gente perde: DISTINCT opera em todas as colunas selecionadas juntas. Se você colocar "pedido_id" e "data_hora" no DISTINCT, linhas com o mesmo pedido mas horários diferentes continuam contando como únicas. Eu já caí nessa armadilha duas vezes. Uma vez foi num sistema de logs onde o timestamp tinha precisão de milissegundo, então cada evento aparecia como linha separada mesmo sendo o mesmo clique do usuário.
A solução foi truncar o timestamp para minutos antes do DISTINCT. Isso reduziu o ruido sem comprometer a análise.
👉 Clique no botão abaixo para saber mais sobre o assunto!
onde isso falha completamente
CONTAGEM deduplicada não é solução mágica. Existem cenários onde o "how many how many" não deve ser resolvido assim. Se a sua tabela é muito grande — digamos, mais de 50 milhões de linhas — rodar DISTINCT antes do COUNT pode transformar uma query de segundos em uma query de minutos. O banco precisa fazer um sort ou hash em memória. Em sistemas sem enough RAM, isso vira swap e a coisa travaria.
Nesses casos, a alternativa é usar aproximações. PostgreSQL tem o APPROX_COUNT_DISTINCT que dá uma estimativa com margem de erro de 2-3%. Em tabelas gigantes isso corta o tempo de 4 minutos para 8 segundos. A desvantagem é que você perde precisão exata. Se o relatório vai pra diretoria, eles vão querer o número certo, não o aproximado. Outro problema comum: campos com nulos. O DISTINCT trata nulos como iguais entre si. Ou seja, todas as linhas com campo-chave nulo viram uma única entrada. Isso pode inflacionar ou deflacionar seus números dependendo de como o dado foi coletado. Eu aprendi isso na prática quando um campo de "codigo_promocao" tinha nulos para promoções normais, e o DISTINCT achava que todas aquelas linhas eram a mesma promoção.
how many how many na prática: um exemplo real
Ultimamente precisei resolver isso num projeto de analytics de app mobile. Tinhamos uma tabela com 12 milhões de eventos de sessão. A pergunta era "quantos usuários únicos tiveram pelo menos uma sessão hoje?". A resposta ingênua seria COUNT(DISTINCT user_id). Mas a tabela também registrava eventos internos do app, como atualizações de cache, que aconteciam múltiplas vezes por sessão sem contar como usuário novo. O que fiz foi filtrar primeiro por tipo_de_evento = 'sessao_inicio', depois aplicar o COUNT(DISTINCT user_id). Isso mudou o resultado de 840 mil para 62 mil. Um erro de 13x. Ninguém tinha percebido porque o painel mostrava os dois números lado a lado e a diferença era considerada "ruído de coleta". Na verdade era lógica de negócio mal aplicada.
A lição é básica mas esquecida: definir o que é "único" requer entender o domínio, não apenas executar funções de agregação. Você precisa saber o que aquela linha representa antes de contar.
resumo sem conclusão
O conceito de "how many how many" resume-se a entender que existem pelo menos duas camadas de contagem em qualquer sistema de dados: a bruta e a lógica. A bruta é o que a tabela mostra. A lógica é o que o negócio realmente quer saber. O gap entre elas é onde erros acontecem, e é onde a maioria dos analistas gasta tempo demais tentando consertar números que nunca fizeram sentido. Dica rápida: sempre pergunte "o que esse campo define como único?" antes de rodar qualquer COUNT. Se a resposta for "eu não sei", você já encontrou o problema.
