Solucionado (ver solução)

Importante

Você está vendo a versão anterior da nova experiência da Alura que estamos preparando para você. Em breve, ela ganha uma identidade visual novinha totalmente pensada em potencializar seus estudos!

Solucionado
(ver solução)
3
respostas

[Projeto] Desafio: ajuste de valores em bases de produtos

Olá, pessoal.

Essa postagem tem o objetivo de apresentar a minha solução para a tarefa Desafio: ajuste de valores em bases de produtos . Nesse curso, estamos analisando uma base de dados sqlite da empresa Zoop MegaStore. A tarefa pede para que analisar os preços dos produtos, identificando quais estão fora da faixa especificada e corrigindo. Como a minha solução não coube dentro do limite de post do fórum, vou incluir esse link para a solução no Github.

3 respostas

Fala, Myke! Tudo bom?

Agradeço por compartilhar sua consulta no fórum!

Curti demais como explorou o UNION para consolidar diferentes produtos com SQL, compreendeu perfeitamente a importância do BETWEEN para definir faixas de preço e utilizou bem o ROUND para calcular o percentual de aceitação.

Se quiser aprofundar ainda mais, algumas boas práticas são:

  • Legibilidade: usar aliases claros para colunas e tabelas.
  • Performance: evitar subconsultas repetitivas, preferindo agregações diretas.
  • Escalabilidade: centralizar regras em tabelas auxiliares em vez de hardcode no SQL.

Continue postando suas soluções! Além de ganhar pontos de XP na plataforma, você pode ajudar outros estudantes no fórum.

Ah, uma pergunta: você prefere manter a consulta mais explícita com vários UNION para clareza ou adotar uma versão mais compacta com CASE e JOIN para facilitar manutenção futura?

Abraço e bons estudos!

Alura Conte com o apoio da comunidade Alura na sua jornada. Abraços e bons estudos!

Fala, Daniel! tudo certo?

A respeito da última consulta, eu não estava muito contente porque achei muito verbosa, apesar de trazer os resultados em um formato útil que permitiu bons insights, foi necessário escrever a mesma condição varias vezes e acho que é difícil de interpretar pala própria leitura do SQL, mas até aquele momento eu não tinha conseguido escrever isso de outra forma. Agora que eu cheguei na última aula do curso SQLite online:
Análise de dados com SQL
e aprendi sobre a cláusula WITH, resolvi reescrever aquela consulta, pensando em criar tabelas temporárias e transformar gradualmente os dados. Em primeiro lugar eu acrescentei uma coluna aceitável para definir se cada produto está dentro da faixa de preço. Com base nessa tabela eu criei a agregação por nome do produto, contando os aceitáveis, não aceitáveis e total, por último selecionei as colunas na ordem que eu queria exibir e acrescentei o percentual de aceitação. Vejo que usar a cláusula WITH melhora muito a legibilidade do SQL, porque é possível escrever cada transformação de cima para baixo, como um pipeline de transformações. Em contra partida, usar subconsultas obriga quem está analisando o código SQL a ler de dentro para fora, localizando as subconsultas mais simples e entendendo cada uma que seria base da consulta mais cosulta mais complexa. Por fim, vou acrescentar como a consulta ficou após as modificações.

WITH
    ProdutosComTagDeAceitacao AS (
        SELECT
            *,
            (nome_produto = 'Bola de Futebol' AND preco BETWEEN 20 AND 100
            OR nome_produto = 'Chocolate' AND preco BETWEEN 10 AND 50
            OR nome_produto = 'Celular' AND preco BETWEEN 80 AND 5000
            OR nome_produto = 'Livro de Ficção' AND preco BETWEEN 10 AND 200
            OR nome_produto = 'Camisa' AND preco BETWEEN 80 AND 200) AS aceitavel
        FROM produtos
    ),
    ProdutosAgregadosPorAceitacao AS (
        SELECT
            nome_produto,
            SUM(aceitavel) AS aceitaveis,
            SUM(NOT aceitavel) AS inaceitaveis,
            COUNT(*) AS total FROM ProdutosComTagDeAceitacao
        GROUP BY nome_produto
    )
SELECT
    nome_produto,
    aceitaveis,
    inaceitaveis,
    ROUND(aceitaveis * 100.0 / total, 2) AS percentual_aceitacao,
    total
FROM ProdutosAgregadosPorAceitacao;
solução!

Bom dia, Myke!

Você fez uma ótima análise sobre a diferença entre manter consultas explícitas com vários UNION e adotar uma versão mais compacta com CASE e JOIN. O ponto central é justamente o equilíbrio entre clareza e manutenção futura.

  • UNION: deixa cada condição bem separada, o que pode facilitar a leitura inicial, mas tende a gerar repetição e verbosidade.
  • CASE + JOIN: concentra a lógica em menos blocos, reduz redundância e facilita ajustes futuros, especialmente quando novas regras precisam ser adicionadas.

Sua escolha de usar WITH (CTEs) já mostra uma evolução significativa, porque organiza o raciocínio em etapas claras e sequenciais. Se somar isso ao uso de CASE e JOIN, você consegue manter a legibilidade e ainda ganhar em eficiência e manutenção.

Parabéns pela forma como você está amadurecendo suas consultas SQL, é exatamente esse tipo de reflexão que diferencia um bom analista de dados de alguém que apenas “faz funcionar”.

Forte abraço!