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

03 Analisando a performance de proprietários com MySQL

Vejam a comparação abaixo:
03 Analisando a performance de proprietários
03 Analisando a performance de proprietários
03 Analisando a performance de proprietários

Resposta
Insira aqui a descrição dessa imagem para ajudar na acessibilidade
Insira aqui a descrição dessa imagem para ajudar na acessibilidade
Insira aqui a descrição dessa imagem para ajudar na acessibilidade
sqL

sql-- 1. Criando tabelas de teste simplificadas
CREATE TABLE hospedagens (hospedagem_id INT, proprietario_id INT);
CREATE TABLE alugueis (hospedagem_id INT, data_inicio DATE, data_fim DATE, preco_total DECIMAL);

-- 2. Inserindo o cenário fictício do teste
INSERT INTO hospedagens VALUES (1, 100), (2, 100);
INSERT INTO alugueis VALUES
(1, '2025-01-01', '2025-06-01', 15100), -- Imóvel 1 (Antigo)
(1, '2025-07-01', '2025-10-18', 10900), -- Imóvel 1 (Antigo)
(2, '2025-12-20', '2025-12-28', 1600); -- Imóvel 2 (Novo instalado em Dezembro)

-- 3. Query Corrigida e Realista
WITH MetricasPorImovel AS (
SELECT
h.proprietario_id,
h.hospedagem_id,
SUM(DATEDIFF(a.data_fim, a.data_inicio)) AS dias_ocupados,
-- Calcula o ciclo de vida individual do imóvel para evitar o "tempo fantasma"
DATEDIFF(MAX(a.data_fim), MIN(a.data_inicio)) AS dias_disponibilidade_real
FROM hospedagens h
JOIN alugueis a ON h.hospedagem_id = a.hospedagem_id
GROUP BY h.proprietario_id, h.hospedagem_id
)
SELECT
proprietario_id,
ROUND((SUM(dias_ocupados) / SUM(dias_disponibilidade_real)) * 100, 2) AS taxa_ocupacao_realista
FROM MetricasPorImovel
GROUP BY proprietario_id;

1 resposta

Olá, Fábio. Como vai?

É simplesmente fantástico acompanhar o desdobramento dessa análise! As imagens que você compartilhou trazem uma clareza visual enorme para o problema da "disponibilidade fantasma". O exemplo comparativo entre a Alternativa A (simplista) e a realidade (individualizada) deixa claro como uma métrica mal modelada pode "punir" injustamente um proprietário que acabou de cadastrar um novo imóvel.

Sua contribuição é um exemplo perfeito de como o SQL deve ser utilizado: como uma ferramenta para traduzir a realidade de negócios em números precisos, e não apenas como um comando para gerar qualquer resultado.

Para quem está acompanhando este tópico, vale destacar os pontos principais que o Fábio provou com essa simulação:

  • A Falha da Alternativa A: Ela assume que todos os imóveis de um proprietário estiveram disponíveis desde a data do primeiro aluguel do imóvel mais antigo. No seu exemplo, o imóvel novo (cadastrado em dezembro) acaba sendo "cobrado" por não ter sido alugado entre janeiro e novembro, o que derruba a taxa de ocupação de forma irreal.
  • A Elegância da CTE (WITH): Ao isolar o cálculo por hospedagem_id dentro da subconsulta (CTE), você garante que o MAX e o MIN de datas sejam relativos a cada imóvel individualmente. Só depois disso é que você soma os resultados para consolidar o dado do proprietário.
  • Lógica de Agregação: O script final que você postou é uma aula de como contornar as limitações de funções de agregação aninhadas, tratando a granularidade dos dados de forma correta antes da sumarização final.

Esta discussão eleva muito o nível do fórum, pois mostra que na Ciência de Dados, o "certo" depende de quão próximo da realidade o seu modelo consegue chegar. Parabéns pela persistência na análise e por compartilhar o código completo para teste!

Espero que possa ter lhe ajudado!