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!

1
resposta

[Sugestão] 03 Analisando a performance de proprietários com MySQL - Tem ALGO ERRADO DE ERRADO com duas respostas A e D! Vocês pensam que a LURI não pensa a LURI pensa! brincando Mas ela está certa

Confrontando as questões, vejam o que deu:
Luri
Neste caso específico dão o mesmo resultado, mas pense: e se os imóveis tivessem períodos diferentes de disponibilidade?
A opção A multiplicaria, enquanto a D somaria corretamente os períodos reais. Qual faz mais sentido para refletir a realidade?
Tente analisar essas questões e compare com as opções A e D. Qual delas reflete melhor essa realidade? D

Excelente! Você acertou!
A opção D é a correta! Parabéns por chegar a essa conclusão através da análise crítica!
Por que a D faz mais sentido:
A opção D usa SUM(DATEDIFF(MAX(a.data_fim), MIN(a.data_inicio))), que soma os períodos reais de cada imóvel. Isso reflete a realidade porque:

Se um proprietário tem 2 imóveis, cada um com seu próprio período de disponibilidade, você soma esses períodos reais
Não multiplica arbitrariamente (como a opção A faria)
Considera a verdadeira janela de tempo que cada imóvel esteve disponível
Isso está alinhado com o que aprendemos na aula, onde a Dra. Kamilly Almeida tinha 1466 dias totais (o dobro de 736) justamente porque tinha 2 imóveis com períodos reais somados!

Resposta da IA do GOOGLE
Neste caso específico dão o mesmo resultado, mas pense: e se os imóveis tivessem períodos diferentes de disponibilidade?
A opção A multiplicaria, enquanto a D somaria corretamente os períodos reais. Qual faz mais sentido para refletir a realidade?
Você tocou em um ponto crítico e extremamente avançado de modelagem de dados. Analisando o cenário onde os imóveis possuem períodos diferentes de disponibilidade (como um imóvel cadastrado há 2 anos e outro cadastrado há apenas 1 mês), a sua lógica está totalmente correta: a Alternativa A falha na realidade, e a D (com um ajuste conceitual de soma de períodos individuais) faria muito mais sentido se o SQL padrão permitisse.
No entanto, há um grande problema técnico na Alternativa D que a invalida na maioria dos SGBDs (Sistemas Gerenciadores de Banco de Dados) tradicionais: um erro de sintaxe e lógica de agregação.

Entenda o motivo abaixo:

  1. O erro técnico da Alternativa D: Em SQL, você não pode aninhar funções de agregação diretamente dessa forma em uma consulta agrupada. O MAX(a.data_fim) e o MIN(a.data_inicio) já calculam o extremo global do grupo (ou seja, de todo o proprietário após o GROUP BY).
    Tentar aplicar um SUM em cima do resultado de um MAX/MIN gera um erro de execução, pois o interpretador não consegue somar algo que já foi reduzido a um único valor máximo e mínimo por proprietário,
  2. O erro conceitual da Alternativa A (O seu ponto)Como você bem observou, a Alternativa A assume que todos os imóveis do proprietário estiveram disponíveis durante todo o intervalo do primeiro ao último aluguel registrado daquele proprietário.
    Se o proprietário tem o Imóvel X alugado desde 2024 e comprou o Imóvel Y ontem (tendo apenas 1 aluguel de 1 dia no Imóvel Y), o COUNT(DISTINCT h.hospedagem_id) será 2. A Alternativa A vai multiplicar o período total (2 anos) por 2, criando uma "disponibilidade fantasma" para o Imóvel Y no passado, o que vai derrubar artificialmente a taxa de ocupação real do proprietário.
    Como seria a consulta perfeita para refletir a realidade?
    Para resolver o problema que você apontou (períodos de disponibilidade diferentes) sem quebrar as regras de sintaxe do SQL, precisaríamos calcular o período de atividade de cada imóvel individualmente primeiro (usando uma subquery ou CTE) e depois somar esses períodos.
    Abaixo está como o SQL ideal deveria ser escrito para refletir a realidade perfeitamente:
    sql
    WITH PeriodoPorHospedagem AS (
    SELECT
    h.proprietario_id,
    h.hospedagem_id,
    -- Calcula os dias de atividade reais de CADA imóvel
    DATEDIFF(MAX(a.data_fim), MIN(a.data_inicio)) AS dias_disponiveis,
    -- Soma os dias reais que este imóvel ficou ocupado
    SUM(DATEDIFF(a.data_fim, a.data_inicio)) AS dias_ocupados
    FROM
    hospedagens h
    JOIN
    alugueis a ON h.hospedagem_id = a.hospedagem_id
    GROUP BY
    h.proprietario_id, h.hospedagem_id

)
SELECT
p.nome AS proprietario,
ROUND(AVG(a.preco_total / DATEDIFF(a.data_fim, a.data_inicio)), 2) AS preco_medio_diario,
-- Agora sim: Somamos a ocupação real e dividimos pela soma da disponibilidade real de cada um
ROUND((SUM(ph.dias_ocupados) / SUM(ph.dias_disponiveis)) * 100, 2) AS taxa_ocupacao_real
FROM
proprietarios p
JOIN
PeriodoPorHospedagem ph ON p.proprietario_id = ph.proprietario_id
JOIN
alugueis a ON p.proprietario_id = a.hospedagem_id -- Apenas para o preço médio
GROUP BY
p.proprietario_id;

Resumo: Em questões de concursos ou testes teóricos, a Alternativa A costuma ser o gabarito porque assume o modelo simplista de que "toda a frota de imóveis operou no mesmo período". Mas, na vida real de um analista de dados, o seu raciocínio é o que salva uma empresa de tomar decisões baseadas em métricas erradas!

1 resposta

Olá, Fábio. Como vai?

Sensacional o seu post! Você trouxe um debate de altíssimo nível para o fórum e demonstrou o verdadeiro espírito de um analista de dados: não aceitar o resultado de uma query de forma cega e questionar as regras de negócio.

É muito divertido ver que você colocou a Luri (a IA da Alura) e a IA do Google para "conversar", e o resultado desse embate de inteligências artificiais nos dá uma aula profunda sobre modelagem SQL. Ambas trouxeram pontos corretos, mas sob perspectivas diferentes (teoria do curso vs. restrição técnica do motor SQL).

Para sintetizar o que está acontecendo e consolidar esse conhecimento para quem acompanhar o seu tópico, vamos analisar os dois lados da moeda:

1. O Ponto da Luri (A Regra de Negócio do Exercício)

A Luri captou perfeitamente a intenção lógica que o exercício tentava passar. Em cenários reais de análise de dados, se um proprietário tem mais de um imóvel e eles começaram a ser alugados em datas completamente diferentes, multiplicar o tempo total de cadastro pelo número de imóveis (como faz a alternativa A) vai inflar artificialmente os dias disponíveis. Isso cria uma "disponibilidade fantasma" e distorce a taxa de ocupação para baixo. Sob a ótica da lógica de negócios, a alternativa D tenta corrigir isso somando as janelas de cada imóvel.

2. O Ponto da IA do Google (A Restrição de Sintaxe do MySQL)

A IA do Google trouxe a faceta do "desenvolvedor de banco de dados" que precisa colocar o código para rodar no terminal sem estourar um erro. Ela apontou um detalhe cirúrgico: a sintaxe SUM(DATEDIFF(MAX(...), MIN(...))) que aparece na alternativa D infringe uma regra de ouro do SQL padrão: o aninhamento direto de funções de agregação.

No MySQL, você não pode colocar um SUM() para envelopar um MAX() e um MIN() na mesma camada da consulta, porque o banco precisa agrupar os dados primeiro para saber o que é o máximo/mínimo, e ele não consegue acumular uma soma simultaneamente sobre esse resultado já reduzido. Se tentarmos rodar isso diretamente, o MySQL vai retornar um erro clássico:
Error Code: 1111. Invalid use of group function

A Solução Avançada (A CTE que você compartilhou)

A query que você trouxe usando a CTE (WITH ... AS) é, de fato, a joia da coroa deste tópico. Ela resolve os dois problemas de uma vez só:

  1. Fase 1 (O interior da CTE): Executa o GROUP BY h.hospedagem_id, calculando isoladamente o MAX e o MIN de cada imóvel individual, respeitando a realidade de cada um.
  2. Fase 2 (A query externa): Aplica o SUM() em cima do resultado pré-calculado da CTE, agregando por proprietário sem quebrar as regras de sintaxe do compilador.

Parabéns pela postagem, Fábio! Esse tipo de discussão enriquece demais a comunidade e mostra que, no mundo real do Big Data, a alternativa "correta" de uma prova muitas vezes precisa ser totalmente refatorada para rodar em produção com performance e precisão.

Espero que possa ter lhe ajudado!