Histórico com SCD Type 2

Na Nekt, ative o SCD Type 2 na tabela de origem. Cada mudança vira uma linha nova com _available_from (início da vigência), _available_until (fim, nulo na versão vigente) e _deleted. O histórico vale a partir do dia em que foi ligado: a primeira versão de cada entidade é o estado naquele dia, não na criação.

Cada versão pode ganhar um código substituto novo. Numa dimensão versionada de corretora, os códigos mudavam a cada versão da mesma conta. Identifique a entidade pela chave de negócio estável (id da assinatura, código da conta, id do negócio) e use o código substituto só para ligar o fato à versão daquela data.

O estado numa data é a versão em que _available_from é menor ou igual à data e _available_until é nulo ou maior que ela. Para cruzar um fato com uma dimensão (o assessor da captação, o dono do negócio ganho, o plano da fatura), use a data do fato, não a versão de hoje.

Para o dia a dia, publique uma visão só com a versão vigente (_available_until nulo e _deleted falso) e mantenha a linha do tempo completa numa tabela à parte. Quem consulta a tabela de versões sem filtro conta cada entidade várias vezes.

_available_from e _available_until são instantes em UTC. Converta para o fuso do negócio (America/Sao_Paulo) antes de cortar o dia ou o mês, senão mudanças feitas à noite caem no dia seguinte e a foto de fim de mês pega a versão errada.

O SCD grava uma versão por sincronização que encontrou mudança, então a mesma entidade pode ter várias versões no mesmo dia. Na foto diária, use a última versão de cada entidade em cada dia. Na foto de fim de mês, use a versão vigente no último instante do mês, com o mesmo corte para todas as entidades.

Uma versão nova pode ter mudado só o período de cobrança, a última fatura ou outro campo técnico. Para contar mudanças de status, de dono ou de plano, compare o campo com o da versão anterior. Colunas de controle como _nekt_sync_at nunca entram na comparação, e _available_from diz quando a sincronização viu a mudança, não quando ela aconteceu na fonte.

Algumas APIs guardam poucos dias: eventos do Stripe por cerca de 30, analytics de e-mail por cerca de 45, coleções com TTL no banco. A sincronização completa reescreve a tabela com a janela vigente e apaga o resto. Acumule numa tabela própria por merge, com chave e dia, que só cresce, e nunca troque esse merge por overwrite.

Uma transformação SQL reconstrói a tabela inteira a cada execução e não guarda passado. Para fotografar um número calculado (carteira, saldo, MRR do dia), use um notebook que lê a própria saída, mantém os dias anteriores e substitui só o dia atual. Assim, rodar duas vezes no mesmo dia não duplica a foto.

O resultado de um mês fechado é lido da foto congelada, não recalculado com a regra ou o cadastro de hoje. Correções posteriores entram como ajuste no mês em que foram descobertas. Numa base real, uma qualificação recalculada a cada execução fez o número de um mês encolher depois de apresentado.