Olá, Carlos Eduardo. Como vai?
Excelente resolução! É muito gratificante ver posts estruturados com esse nível de maturidade técnica no fórum. Como Tech Lead e Engenheiro de Dados, você aplicou conceitos avançados de arquitetura de consultas de forma impecável.
A sua decisão de construir uma Subquery (Subconsulta) no FROM (criando o alias t1) foi cirúrgica. Em SQL, não podemos reutilizar o apelido de uma coluna calculada (como o seu cálculo matemático da distancia) dentro do mesmo nível de projeção do SELECT para construir uma regra de negócio como o CASE. Ao modularizar o cálculo na subquery e aplicar a condicional do frete na query externa, você contornou essa limitação do motor de processamento do banco com maestria, mantendo o código limpo e legível.
A engenharia por trás das suas escolhas de funções numéricas merece destaque:
- Fórmula de Haversine simplificada (Distância Euclidiana adaptada): O uso combinado de
SQRT e POWER para calcular a hipotenusa das diferenças de coordenadas geográficas (latitude e longitude) multiplicada pelo fator de correção $111.19$ km é uma solução clássica e muito inteligente para aproximações de geolocalização em bancos relacionais. - Uso do
CEILING: Perfeito para a lógica de empacotamento. Se uma caixa comporta até 8 produtos e o cliente compra 9, ele precisa de 2 caixas. O CEILING (teto) garante esse arredondamento para cima de forma exata, impedindo prejuízos na operação logística. - Uso do
ROUND: Excelente para limpar as casas decimais flutuantes da distância na entrega do relatório final.
Para fins de documentação visual e para auxiliar os colegas do fórum que estão tentando entender como os dados trafegam por essa consulta em camadas, o esquema abaixo mapeia a ordem de execução lógica do banco de dados na sua estrutura:
Uma sutil observação de portfólio (Boas Práticas de Sintaxe)
O seu código roda perfeitamente no MySQL Workbench (como mostra o seu print). Contudo, há uma pequena inconsistência de sintaxe na linha 8 que, dependendo do SGBD que o estudante estiver usando (como PostgreSQL ou SQL Server), pode lançar um erro de compilação:
END AS 'frete'
No padrão ANSI SQL, aspas simples servem exclusivamente para delimitar literais de texto (strings como 'São Paulo'). Para apelidar colunas (aliases), devemos usar aspas duplas ("frete"), colchetes ([frete]) ou, idealmente em nomes simples, nenhuma aspa:
END AS frete
Essa convenção impede que o interpretador de determinados bancos confunda o nome da coluna com um texto estático puro.
Seu script é um exemplo prático brilhante de como transformar dados brutos de logística em insights financeiros e operacionais de alto valor para qualquer empresa. Parabéns pela entrega e pela generosidade em compartilhar a query formatada com a comunidade!
Espero que possa ter lhe ajudado!
