Encontrar clientes que atendem a todos os requisitos

Encontrar clientes com algum requisito é simples usando join. Encontrar quem atende a todos é outra pergunta: uma correspondência prova presença, não completude. A diferença aparece em permissões, certificações, pacotes de produtos e preparação para migração.

Expressar todos como nenhum ausente

Mantenha o cliente quando não existir requisito faltante. O NOT EXISTS externo procura uma exigência não atendida. O interno verifica se falta aquela capacidade específica para o cliente. Cada negação corresponde a uma condição de negócio concreta.

CREATE TABLE #Customers(CustomerId int PRIMARY KEY);
CREATE TABLE #Required(Capability varchar(10) PRIMARY KEY);
CREATE TABLE #Has(CustomerId int,Capability varchar(10),
 PRIMARY KEY(CustomerId,Capability));
INSERT #Customers VALUES(1),(2),(3);
INSERT #Required VALUES('A'),('B');
INSERT #Has VALUES(1,'A'),(1,'B'),(1,'C'),(2,'A');
SELECT c.CustomerId FROM #Customers AS c
WHERE NOT EXISTS
(SELECT 1 FROM #Required AS r WHERE NOT EXISTS
 (SELECT 1 FROM #Has AS h WHERE h.CustomerId=c.CustomerId
  AND h.Capability=r.Capability))
ORDER BY c.CustomerId;

O cliente 1 atende A e B; C adicional não o desqualifica. O cliente 2 não possui B e o 3 não tem capacidades. As chaves primárias garantem uma ocorrência por associação e por requisito.

A consulta de faltantes explica o resultado, transformando sim ou não em ações. Para operações, essa lista costuma ser mais útil que uma porcentagem com denominador invisível.

SELECT c.CustomerId,r.Capability AS MissingCapability
FROM #Customers AS c CROSS JOIN #Required AS r
WHERE NOT EXISTS(SELECT 1 FROM #Has AS h
 WHERE h.CustomerId=c.CustomerId AND h.Capability=r.Capability)
ORDER BY c.CustomerId,r.Capability;

Definir o conjunto vazio

Sem requisitos, a primeira consulta retorna todos os clientes: nenhuma exigência está faltando. Esse é o significado lógico usual, mas o processo pode exigir configuração antes de aprovar. Nesse caso, acrescente um EXISTS separado sobre os requisitos, mantendo explícita essa regra.

Todos os requisitos também não significa exatamente os requisitos. O cliente 1 passa apesar de C. Para correspondência exata, acrescente uma verificação rejeitando capacidades fora do conjunto obrigatório. Um extra pode ser irrelevante ou proibido; defina isso antes de usar o resultado em decisões de acesso.

Evite identificadores NULL sem significado definido. Igualdade não combina dois NULL como dois códigos conhecidos. Rejeite ou reconcilie valores desconhecidos antes da avaliação, em vez de tratá-los implicitamente como satisfação de uma exigência.

Comparar alternativas equivalentes

GROUP BY com COUNT(DISTINCT Capability) também funciona se contar apenas capacidades exigidas e comparar com a quantidade correta de requisitos. Contar todas as capacidades é errado: duas capacidades quaisquer não atendem a duas específicas. Duplicatas também aumentam COUNT quando não existe unicidade.

A chave cliente-capacidade favorece verificações direcionadas. Um índice complementar capacidade-cliente pode ajudar quando a busca começa em poucos requisitos. Meça benefício contra custo de escrita e armazenamento. Examine planos reais com volumes representativos: NOT EXISTS aninhados não obrigam loops procedimentais aninhados.

Se requisitos ou associações mudam durante a avaliação, defina uma visão consistente para decisões reproduzíveis. Grave a versão das regras junto da aprovação quando precisar explicar sua base posteriormente. Uma consulta atual não reconstrói uma decisão anterior depois que as regras mudaram.

Teste conjunto vazio, nenhuma associação, correspondência exata, falta, extras e duplicatas rejeitadas. Confira se diagnóstico e decisão usam a mesma versão, evitando resultados contraditórios. Acrescente um cliente com muitas capacidades irrelevantes para demonstrar que igualdade de quantidades não basta. Verifique ainda alterações concorrentes de regras durante o teste de integração. O resultado deve selecionar corretamente e explicar os faltantes sem confundir algum, todos e exatamente.

Registre também qual requisito mudou quando uma aprovação antiga precisar ser reavaliada.

Referências técnicas: Microsoft Learn: EXISTS · Microsoft Learn: COUNT.