Conjuncao E Disjuncao
O que funciona na prática quando você precisa filtrar dados com conjunção e disjunção
Muita gente trava na hora de aplicar conjuncao e disjuncao em filtros de banco de dados ou planilhas porque aprendeu a definição teórica mas nunca lidou com dados sujos do mundo real. A lógica é simples no papel — AND junta condições, OR abre opções — mas quando você tem tabelas com campos mal formatados, nulos inconsistente e campos que deveriam ser booleanos mas são texto, tudo desmorona rápido. Aqui vai o jeito que eu uso desde 2019, após ter perdido três dias refazendo uma query que retornava resultados errados porque um campo de Status continha tanto "ativo" quanto "Ativo" e "ATIVO" dependendo de quem inseriu os dados.
Implementando conjuncao e disjuncao em SQL e Excel
Em SQL, a conjunção usa o operador AND e a disjunção usa o OR. Parece óbvio, mas o problema real aparece quando você precisa combinar ambos em uma mesma query com subconsultas e GROUP BY. Vou mostrar com um exemplo prático que eu mesmo usei numa auditoria de vendas. Suponha que você tenha uma tabela vendas com colunas: cliente_id, produto, valor, data, estado. Você precisa encontrar todos os clientes que compraram pelo menos dois produtos diferentes (AND: produto diferente E valor total acima de 500) OU que tenham feito uma compra superior a 2000 em um único pedido (OR). A query correta seria algo assim:
SELECT cliente_id FROM vendas GROUP BY cliente_id HAVING (COUNT(DISTINCT produto) >= 2 AND SUM(valor) >= 500) OR MAX(valor) >= 2000; A parte que ninguém explica nos tutoriais é o parênteses. Sem ele, o ORDER OF OPERATIONS do SQL avalia AND antes de OR, o que pode dar resultados completamente diferentes do esperado. Na minha auditoria, esqueci os parênteses na primeira versão e o relatório trouxe 340 clientes a mais do que deveria porque a condição OR estava sendo aplicada sobre cada linha individualmente, não sobre o grupo. No Excel, a situação é ainda mais traiçoeira. A função SE combinada com E e OU funciona, mas apenas até 7 níveis de aninhamento na versão antiga. Na prática, eu nunca vou além de três condições por fórmula porque depois fica ilegível e propenso a erro. O que eu faço é criar colunas auxiliares:
Na coluna D eu coloco =E(B2>0;C2="ativo") para a condição de conjunção. Na coluna E, =OU(D2;C2>2000) para a disjunção final. Isso separa a lógica em partes menores e facilita a depuração quando algo não batia.
Um caso concreto que quebrou meu filtro e como resolvi
Num projeto de CRM, tínhamos que extrair leads que fossem conjunção de: setor tecnológica E localização São Paulo E status qualificado, ou então disjunção de: valor potencial acima de 50 mil OU indicação de parceiro. O filtro funcionava perfeitamente no ambiente de teste com 2.000 registros limpos. Quando subi para produção com 180 mil registros, o tempo de resposta passou de 2 segundos para 47 segundos, e a query caiu. O problema era índice. Eu tinha índices em cada coluna individualmente, mas nenhuma combinação de índices cobrindo a conjunção das três condições. A solução foi criar um índice composto (setor, localizacao, status) na ordem em que as condições apareciam na cláusula WHERE. O tempo caiu para 1,8 segundo. A disjunção, por sua vez, não pôde ser indexada da mesma forma — OR sempre força um scand mais amplo — então eu usei UNION ALL entre as duas consultas separadas em vez de um único OR. Isso evitou o materialization de um result set gigante. União ALL ao invés de OR reduziu o tempo de execução em cerca de 60% nesse cenário específico. Não é uma regra universal — depende do otimizador e do tamanho dos dados — mas vale testar sempre que um OR estiver estrangulando a query.
Erros que você vai cometer e como evitar
O primeiro erro clássico é tratar NULL como valor válido. Em SQL padrão, NULL AND qualquer_coisa resulta em NULL, não em FALSE. Isso significa que registros com campo nulo simplesmente desaparecem do resultado sem aviso. A correção é usar COALESCE(campo, '') ou ISNULL para normalizar antes de comparar. O segundo erro é confundir a semântica de conjunção e disjunção na modelagem. Conjuga significa TODAS as condições precisam ser verdadeiras simultaneamente. Disjunção significa QUE QUALQUER uma basta. Misturar esses conceitos leva a relatórios com dados duplicados ou incompletos, e você só percebe quando someone questiona um número que não faz sentido. Outro ponto cego: em planilhas, a função E retorna FALSE se algum argumento for FALSE, mas ignora argumentos textuais vazios como se fossem verdadeiros. Se você está filtrando dados exportados de um sistema legado, campos vazios podem passar por filtros que você achava que bloqueavam.
Quando conjunção e disjunção não resolvem o problema
Existem cenários em que Combinar AND e OR não é a abordagem certa. Se você precisa de lógica complexa como "todos os clientes que compraram X mas não Y e nunca tiveram conta cancelada nos últimos 12 meses", a query com condições aninhadas vira uma bola de neve. Nesses casos, eu prefiro processar os dados em Python ou R com pandas, onde operações de conjunção e disjunção ficam mais legíveis com operadores & e |, e você pode inspecionar cada etapa intermediária. Planilhas também chegam num limite prático por volta de 50 mil linhas com fórmulas aninhadas. Depois disso, a performance degrada visivelmente e a manutenibilidade zero. Migrar para um banco de dados ou pelo menos para uma consulta Power Query resolve.
Resumo prático sem rodeios
Use parênteses sempre que combinar AND e OR. Crie índices compostos para a parte de conjunção e considere UNION ALL para substituir ORs quentes em queries pesadas. Normalice NULLs com COALESCE. Separe lógica complexa em colunas auxiliares no Excel ou em CTEs no SQL. E testee sempre no volume real de dados, não em amostras pequenas, antes de confiar no resultado. Isso é o básico que funciona na prática. O resto vem de ir quebrando coisa até entender porquê quebra.
