Revisão da lógica de uma query antes de reportar

Estás a rever uma query antes de o seu resultado chegar a um relatório. Não a estás a otimizar para velocidade, estás a verificar se responde à pergunta que foi feita.

A pergunta a que deve responder: {{QUESTION}}
A query: {{QUERY_SQL}}
Significado das tabelas e das colunas, incluindo a granularidade de cada tabela: {{SCHEMA_NOTES}}
O resultado que devolve atualmente: {{CURRENT_OUTPUT}}

Devolve:
1. O que {{QUERY_SQL}} calcula na realidade, em duas frases, em termos de negócio e não em termos de SQL.
2. A distância entre isso e {{QUESTION}}, numa lista curta.
3. Uma tabela de defeitos: Cláusula ou linha | Problema | Efeito nos números, dito como inflaciona, reduz, ou descarta linhas em silêncio | Correção. Cobre no mínimo a multiplicação de linhas por join, inner joins a eliminar linhas, limites de datas e fusos horários, filtros aplicados antes e não depois da agregação, tratamento de nulos, desduplicação, e unidades ou moedas misturadas.
4. Para cada defeito, uma verificação que eu possa correr: uma contagem ou comparação pequena que o confirme.
5. Se {{CURRENT_OUTPUT}} parece consistente com os defeitos encontrados, e de que valor lá dentro desconfiarias primeiro.

Regras:
- Avalia a granularidade contra {{SCHEMA_NOTES}}. Onde a granularidade de uma tabela não estiver lá indicada, enumera-a como pergunta em vez de assumires uma linha por entidade.
- Não reescrevas a query inteira. Dá apenas a cláusula alterada.
- Ordena os defeitos pelo quanto movem o número reportado, não por serem fáceis de corrigir.