Tema: data-modelling
-
Como projetar uma tabela de séries temporais somente de inserção no PostgreSQL
Armazene medições em uma tabela particionada por intervalo de tempo, com timestamptz, chave composta de série e tempo, índices adequados ao padrão de consulta (B-tree por série, BRIN para varreduras de tempo na tabela inteira) e retenção feita por detach e drop de partições, em vez de DELETE; as escolhas decorrem de as linhas chegarem em ordem de tempo e saírem em fatias inteiras de tempo.
-
Dimensões que mudam lentamente: sobrescrever, adicionar uma linha ou adicionar uma coluna
Quando um atributo de dimensão muda (um cliente se muda, um produto é reclassificado), o tipo 1 sobrescreve e perde o histórico, o tipo 2 adiciona uma nova linha com datas de vigência e de expiração e um indicador de linha atual, sob uma nova chave substituta, e o tipo 3 guarda o valor anterior em uma coluna extra. As ferramentas de snapshot implementam o tipo 2 comparando, a cada execução, um timestamp de atualização ou um conjunto de colunas.
-
Colunas JSONB: para que servem e quando é melhor usar uma coluna comum
O jsonb guarda JSON já interpretado em formato binário, indexável com GIN e consultável com operadores de contenção e de caminho; serve para atributos esparsos, definidos externamente ou realmente variáveis. Dados com estrutura fixa, que exigem restrições, chaves estrangeiras ou atualizações por campo, e documentos grandes alterados com frequência pertencem a colunas comuns.
-
Registros de consentimento e preferências como dados: o que foi escolhido, quando e por qual canal
Modele as escolhas de uma pessoa como eventos append-only (sujeito, finalidade, escolha, momento, origem, versão do texto), com uma visão derivada do estado atual que todo consumidor lê no ponto de uso; um booleano na linha do usuário não responde o que foi acordado no momento de uma ação nem quais usuários um bug de banner afetou.
-
Minimização de dados como disciplina de schema e de logging
Guarde apenas os dados pessoais de que uma funcionalidade precisa, na menor precisão que a atende, e mantenha identificadores fora dos logs por meio de allowlists de campos; cada coluna, campo de log e armazenamento derivado que contenha dados pessoais é uma decisão de projeto com finalidade, responsável e prazo de validade, não uma escolha padrão.
-
Soft deletes versus tabelas de arquivo
Um soft delete mantém a linha com um marcador deleted_at, de modo que toda consulta precisa filtrá-la e toda restrição de unicidade precisa virar um índice parcial; uma tabela de arquivo move a linha para fora da tabela ativa, mantendo simples as consultas sobre os dados ativos e o histórico num só lugar. A escolha depende de quem lê os dados excluídos e com que frequência, e deve ser codificada em restrições e views, não em cada consulta.
-
Normalização até a terceira forma normal e quando desnormalizar
As formas normais eliminam grupos repetitivos e fatos armazenados em mais de um lugar; na terceira forma normal, toda coluna não chave depende da chave e de nada além dela. Normalize por padrão os dados transacionais e desnormalize apenas em colunas derivadas e nomeadas, mantendo a fonte da verdade normalizada.
-
Constraints declarativas no PostgreSQL: CHECK, UNIQUE e chaves estrangeiras com ON DELETE
As constraints fazem o banco de dados rejeitar estados inválidos para qualquer cliente que escreva nele, e não apenas para a aplicação: CHECK para regras por linha, NOT NULL para valores obrigatórios, UNIQUE para identidade e chaves estrangeiras com uma ação ON DELETE explícita. Escolher a ação referencial e indexar a coluna referenciadora são as duas decisões mais frequentemente ignoradas.
-
Fundamentos do esquema estrela: fatos, dimensões e a declaração da granularidade
Um esquema estrela guarda as medições em tabelas de fatos e o contexto descritivo em tabelas de dimensão, ligadas por chaves. O projeto começa por declarar a granularidade, ou seja, o que uma linha de fato representa, pois toda medida e toda dimensão precisam ser coerentes com ela. Medidas totalmente aditivas somam-se em qualquer dimensão, as semiaditivas não se somam ao longo do tempo, e razões devem ser armazenadas como seus componentes.
-
Pseudonimização versus anonimização como técnicas de engenharia
A pseudonimização troca identificadores diretos por tokens, mantém um caminho de volta (uma chave ou uma tabela de correspondência) e preserva um registro por pessoa; a anonimização busca eliminar a associação entre registros e pessoas para todos. Use HMAC com chave por finalidade para os pseudônimos e trate uma tabela pseudonimizada como dado pessoal que ainda contém quase-identificadores.
-
Colunas de identidade, sequences e por que os IDs gerados têm lacunas
Colunas de identidade são a forma padrão de numerar linhas automaticamente no PostgreSQL; elas usam uma sequence cujos valores são distribuídos fora do controle de transações, então rollbacks, falhas, cache e inserts com ON CONFLICT deixam lacunas. Lacunas são normais; uma numeração sem lacunas exige um contador separado e serializado.
Legível por máquina: JSON