Logando dados analíticos em tabelas separadas

Imagina que você está montando um relatório de vendas da semana. Os cálculos estão feitos, os clientes estão felizes. Mas aí, um mês depois, alguém pede: "Você pode mostrar o que tinha naquele relatório?" Se você não salvou os dados antes, vai ter que reconstruir tudo na mão ou responder "não dá". Isso é chato e pode até queimar seu filme.

Logar dados analíticos resolve várias paradas importantes:

• Guardar histórico: você registra métricas chave (tipo receita, número de pedidos) para períodos específicos.
• Auditoria e diagnóstico: se der ruim, sempre dá pra checar o que foi registrado.
• Comparação de dados: colocando timestamps, dá pra analisar como os indicadores mudam com o tempo.
• Reutilização de dados: as métricas salvas podem ser usadas em outras análises.

Ideia principal: tabela log_analytics

Pra logar dados analíticos, a gente cria uma tabela especial pra guardar todos os indicadores chave. Cada novo resultado é uma nova linha na tabela. Pra sacar como funciona, bora ver um cenário básico.

Exemplo de estrutura da tabela

Na tabela log_analytics vamos guardar dados dos relatórios. Olha a estrutura (DDL — Data Definition Language):

CREATE TABLE log_analytics (
    log_id SERIAL PRIMARY KEY, -- Identificador único do registro
    report_name TEXT NOT NULL, -- Nome do relatório ou métrica
    report_date DATE DEFAULT CURRENT_DATE, -- Data referente ao relatório
    category TEXT, -- Categoria dos dados (tipo região, produto)
    metric_value NUMERIC NOT NULL, -- Valor da métrica
    created_at TIMESTAMP DEFAULT NOW() -- Data e hora do log
);

• log_id: identificador principal do registro.
• report_name: nome do relatório ou métrica, tipo "Vendas Semanais".
• report_date: data referente à métrica. Por exemplo, se for vendas de 1 de outubro, aqui vai 2023-10-01.
• category: ajuda a agrupar os dados, tipo por região.
• metric_value: valor numérico da métrica do relatório.
• created_at: timestamp do log.

Exemplo de inserção de dados em log_analytics

Vamos supor que calculamos a receita de outubro pra região "Norte". Como salvar esse valor?

INSERT INTO log_analytics (report_name, report_date, category, metric_value)
VALUES ('Receita Mensal', '2023-10-01', 'Norte', 15000.75);

Resultado:

Criando uma procedure pra logar

Claro que ninguém vai ficar inserindo dado na mão toda semana ou mês. Então bora automatizar com uma procedure.

Vamos criar uma procedure simples pra logar dados de receita:

CREATE OR REPLACE FUNCTION log_monthly_revenue(category TEXT, revenue NUMERIC)
RETURNS VOID AS $$
BEGIN
    INSERT INTO log_analytics (report_name, report_date, category, metric_value)
    VALUES ('Receita Mensal', CURRENT_DATE, category, revenue);
END;
$$ LANGUAGE plpgsql;

Agora a procedure log_monthly_revenue recebe dois parâmetros:

• category: categoria dos dados, tipo região.
• revenue: valor da receita

Olha como chama essa função pra registrar a receita:

SELECT log_monthly_revenue('Norte', 15000.75);

O resultado vai ser igual ao do INSERT.

Outras ideias pra estrutura de logs

Às vezes a métrica chave não é só uma, mas várias. Bora ver como registrar mais indicadores, tipo número de pedidos ou ticket médio.

Vamos atualizar a estrutura da tabela:

CREATE TABLE log_analytics_extended (
    log_id SERIAL PRIMARY KEY,
    report_name TEXT NOT NULL,
    report_date DATE DEFAULT CURRENT_DATE,
    category TEXT,
    metric_values JSONB NOT NULL, -- Guardando métricas em formato JSONB
    created_at TIMESTAMP DEFAULT NOW()
);

Aqui a novidade é usar o tipo JSONB pra guardar várias métricas num campo só.

Exemplo de inserção na tabela estendida

Vamos supor que queremos salvar três métricas de uma vez: receita, número de pedidos e ticket médio. Olha o exemplo:

INSERT INTO log_analytics_extended (report_name, category, metric_values)
VALUES (
    'Receita Mensal',
    'Norte',
    '{"receita": 15000.75, "pedidos": 45, "ticket_medio": 333.35}'::jsonb
);

Resultado:

Exemplos de uso dos logs: análise de receitas

Vamos supor que queremos saber a receita total de todas as regiões em outubro. Olha a query:

SELECT SUM((metric_values->>'receita')::NUMERIC) AS receita_total
FROM log_analytics_extended
WHERE report_date BETWEEN '2023-10-01' AND '2023-10-31';

Exemplos de uso dos logs: tendências por região

Analisando mudanças de receita por região:

SELECT category, report_date, (metric_values->>'receita')::NUMERIC AS receita
FROM log_analytics_extended
ORDER BY category, report_date;

Tratando erros comuns

Ao logar dados analíticos, dá pra cometer alguns vacilos. Bora falar deles e como evitar.

• Erro: esqueceu de informar categoria ou data. Recomendo definir valores padrão na tabela, tipo DEFAULT CURRENT_DATE.
• Erro: duplicação de registros. Pra evitar duplicidade, dá pra criar um índice único:

  CREATE UNIQUE INDEX unique_log_entry
  ON log_analytics (report_name, report_date, category);
  

• Erro: cálculo de métricas com divisão por zero. Sempre confere o divisor! Usa NULLIF:

  SELECT receita / NULLIF(numero_pedidos, 0) AS ticket_medio FROM pedidos;
  

Aplicação em projetos reais

Logar dados analíticos é útil em várias áreas:

• Varejo: acompanhar receitas e vendas por categoria de produto.
• Serviços: analisar carga de servidores ou apps.
• Finanças: controlar transações e despesas.

Esses dados vão te ajudar não só a explicar o que rolou, mas também a tomar decisões com base no que você vê nos logs. Agora você já sabe como registrar o histórico de dados analíticos no PostgreSQL. Show, tem muito mais coisa boa vindo por aí!