Melhores Práticas de Desnormalização

Documente os invariantes que as colunas desnormalizadas devem preservar. Desnormalize apenas com evidências, propriedade e detecção de desvios - não porque junções parecem lentas em desenvolvimento.

Como Usar Esta Lista

Padronize em 3NF para OLTP; use esta lista apenas ao propor colunas redundantes ou visualizações materializadas.
Cada item verificado deve aparecer na descrição do PR de migração ou no ADR.
Agende consultas de desvio no monitoramento; alerte quando os invariantes forem quebrados.
Reavalie a desnormalização após o ajuste de índices e mudanças de hardware - as junções podem se tornar baratas novamente.

A - Evidências e Escopo

Comprove a dor com pg_stat_statements e EXPLAIN (ANALYZE, BUFFERS). Nenhuma desnormalização sem consultas "quentes" medidas.
Tente índices de cobertura no esquema normalizado primeiro. Índices de FK mais colunas de inclusão frequentemente removem a necessidade de desnormalizar.
Defina a obsolescência aceitável para cópias de leitura. Visualizações materializadas precisam de um SLA de max_staleness documentado.
Mantenha tabelas normalizadas como fonte da verdade. A desnormalização é derivada; você deve ser capaz de recalcular a partir das tabelas base.
Limite a desnormalização a caminhos de acesso específicos. Uma consulta de dashboard não é um motivo para desnormalizar a tabela de fatos principal globalmente.

B - Invariantes e Documentação

Classifique cada coluna redundante: snapshot vs. espelho em tempo real. Snapshots nunca atualizam; espelhos precisam de jobs de atualização.
Adicione COMMENT ON COLUMN para cada campo desnormalizado. Declare o invariante em linguagem clara e a equipe proprietária.
Registre o mecanismo de atualização. Gatilho, job em lote ou agendamento de REFRESH MATERIALIZED VIEW com o proprietário de plantão.
Versionar snapshots JSONB quando a forma muda. Inclua schema_version dentro dos blobs de snapshot.
Adicione SQL de detecção de desvio ao runbook. Compare a coluna desnormalizada com a fonte; alerte sobre incompatibilidade para espelhos.

C - Segurança de Implementação

Prefira gatilhos ou colunas geradas em vez de escritas duplas dispersas na aplicação. Menos caminhos de código significam menos bugs.
Use NOT NULL em colunas de snapshot preenchidas na inserção. Snapshots parciais NULL quebram ferramentas financeiras e de suporte.
Crie índices únicos antes de REFRESH CONCURRENTLY. A atualização concorrente de MV falha sem um índice único.
Atualize MVs pesadas fora do horário de pico ou em réplicas. Picos de IO no primário prejudicam a latência do OLTP.
Planeje a migração de contrato para remover a desnormalização. Colunas desnormalizadas sem datas de encerramento se tornam dívida permanente.

D - Governança

Exija um segundo revisor para PRs de desnormalização. DBA ou engenheiro sênior assina o invariante e o rollback.
Rastreie colunas desnormalizadas em um catálogo de esquema. Novos contratados devem encontrar todos os campos redundantes em uma única consulta de documento.
Re-teste após atualizações de versão principal. Mudanças no planejador podem tornar as junções normalizadas rápidas o suficiente para descartar a desnormalização.
Não desnormalize entre limites de tenant sem tenant_id no invariante. O risco de vazamento entre tenants aumenta.
Faça post-mortem de cada incidente de desvio. Transforme invariantes quebrados em regras de lint ou verificações de CI.

FAQs

Qual é a diferença entre desnormalização de snapshot e espelho?

Snapshots congelam valores em um evento (preço na compra). Espelhos tentam rastrear dados de dimensão em tempo real e precisam de atualização quando a fonte muda.

Como deve ser um COMMENT ON COLUMN?

COMMENT ON COLUMN order_items.unit_price IS
  'SNAPSHOT invariant: unit price at insert; source products.price';

Com que frequência devo executar a detecção de desvio?

Espelhos: diariamente ou a cada hora, dependendo do SLA. Snapshots: apenas quando as regras de negócios mudam retroativamente os dados de origem.

A desnormalização é alguma vez necessária?

Snapshots históricos (unit_price, tax_rate_at_sale) são requisitos de negócios, não truques de desempenho opcionais.

Qual é o maior erro de desnormalização?

Tratar colunas de espelho como snapshots - relatórios mostram e-mails de clientes desatualizados para sempre sem um job de atualização.

As visualizações materializadas devem substituir a desnormalização de colunas?

Prefira MVs quando muitas consultas compartilham a mesma agregação. Prefira desnormalização de colunas quando uma única linha precisa de campos de snapshot incorporados em escritas OLTP.

Como listar todas as colunas desnormalizadas?

Mantenha uma tabela denorm_registry ou use grep em COMMENT ON COLUMN para tags SNAPSHOT / MIRROR em arquivos de migração.

As restrições CHECK podem impor a desnormalização?

Apenas para regras deriváveis (line_total = quantity * unit_price). Espelhos entre tabelas precisam de gatilhos ou jobs.

Quando devo remover a desnormalização?

Quando EXPLAIN mostra que o caminho normalizado atende ao SLO após melhorias de índice ou hardware por dois trimestres consecutivos.

Como isso se relaciona com data warehouses?

Data warehouses desnormalizam por design. A desnormalização OLTP ainda precisa de invariantes porque as aplicações escrevem as mesmas linhas das quais as transações dependem.

Relacionados

Noções Básicas de Normalização - design normalizado de linha de base
Desnormalização Intencional - padrões de implementação
Visualizações Materializadas - mecânica de atualização
Melhores Práticas de Modelagem de Dados - lista de revisão de modelagem

Versões da Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x e PostGIS 3.5+.

Melhores Práticas de Desnormalização

Como Usar Esta Lista

Padronize em 3NF para OLTP; use esta lista apenas ao propor colunas redundantes ou visualizações materializadas.
Cada item verificado deve aparecer na descrição do PR de migração ou no ADR.
Agende consultas de desvio no monitoramento; alerte quando os invariantes forem quebrados.
Reavalie a desnormalização após o ajuste de índices e mudanças de hardware - as junções podem se tornar baratas novamente.

A - Evidências e Escopo

Comprove a dor com pg_stat_statements e EXPLAIN (ANALYZE, BUFFERS). Nenhuma desnormalização sem consultas "quentes" medidas.
Tente índices de cobertura no esquema normalizado primeiro. Índices de FK mais colunas de inclusão frequentemente removem a necessidade de desnormalizar.
Defina a obsolescência aceitável para cópias de leitura. Visualizações materializadas precisam de um SLA de max_staleness documentado.
Mantenha tabelas normalizadas como fonte da verdade. A desnormalização é derivada; você deve ser capaz de recalcular a partir das tabelas base.
Limite a desnormalização a caminhos de acesso específicos. Uma consulta de dashboard não é um motivo para desnormalizar a tabela de fatos principal globalmente.

B - Invariantes e Documentação

Classifique cada coluna redundante: snapshot vs. espelho em tempo real. Snapshots nunca atualizam; espelhos precisam de jobs de atualização.
Adicione COMMENT ON COLUMN para cada campo desnormalizado. Declare o invariante em linguagem clara e a equipe proprietária.
Registre o mecanismo de atualização. Gatilho, job em lote ou agendamento de REFRESH MATERIALIZED VIEW com o proprietário de plantão.
Versionar snapshots JSONB quando a forma muda. Inclua schema_version dentro dos blobs de snapshot.
Adicione SQL de detecção de desvio ao runbook. Compare a coluna desnormalizada com a fonte; alerte sobre incompatibilidade para espelhos.

C - Segurança de Implementação

Prefira gatilhos ou colunas geradas em vez de escritas duplas dispersas na aplicação. Menos caminhos de código significam menos bugs.
Use NOT NULL em colunas de snapshot preenchidas na inserção. Snapshots parciais NULL quebram ferramentas financeiras e de suporte.
Crie índices únicos antes de REFRESH CONCURRENTLY. A atualização concorrente de MV falha sem um índice único.
Atualize MVs pesadas fora do horário de pico ou em réplicas. Picos de IO no primário prejudicam a latência do OLTP.
Planeje a migração de contrato para remover a desnormalização. Colunas desnormalizadas sem datas de encerramento se tornam dívida permanente.

D - Governança

Exija um segundo revisor para PRs de desnormalização. DBA ou engenheiro sênior assina o invariante e o rollback.
Rastreie colunas desnormalizadas em um catálogo de esquema. Novos contratados devem encontrar todos os campos redundantes em uma única consulta de documento.
Re-teste após atualizações de versão principal. Mudanças no planejador podem tornar as junções normalizadas rápidas o suficiente para descartar a desnormalização.
Não desnormalize entre limites de tenant sem tenant_id no invariante. O risco de vazamento entre tenants aumenta.
Faça post-mortem de cada incidente de desvio. Transforme invariantes quebrados em regras de lint ou verificações de CI.

FAQs

Qual é a diferença entre desnormalização de snapshot e espelho?

Snapshots congelam valores em um evento (preço na compra). Espelhos tentam rastrear dados de dimensão em tempo real e precisam de atualização quando a fonte muda.

Como deve ser um COMMENT ON COLUMN?

COMMENT ON COLUMN order_items.unit_price IS
  'SNAPSHOT invariant: unit price at insert; source products.price';

Com que frequência devo executar a detecção de desvio?

Espelhos: diariamente ou a cada hora, dependendo do SLA. Snapshots: apenas quando as regras de negócios mudam retroativamente os dados de origem.

A desnormalização é alguma vez necessária?

Snapshots históricos (unit_price, tax_rate_at_sale) são requisitos de negócios, não truques de desempenho opcionais.

Qual é o maior erro de desnormalização?

Tratar colunas de espelho como snapshots - relatórios mostram e-mails de clientes desatualizados para sempre sem um job de atualização.

As visualizações materializadas devem substituir a desnormalização de colunas?

Prefira MVs quando muitas consultas compartilham a mesma agregação. Prefira desnormalização de colunas quando uma única linha precisa de campos de snapshot incorporados em escritas OLTP.

Como listar todas as colunas desnormalizadas?

Mantenha uma tabela denorm_registry ou use grep em COMMENT ON COLUMN para tags SNAPSHOT / MIRROR em arquivos de migração.

As restrições CHECK podem impor a desnormalização?

Apenas para regras deriváveis (line_total = quantity * unit_price). Espelhos entre tabelas precisam de gatilhos ou jobs.

Quando devo remover a desnormalização?

Quando EXPLAIN mostra que o caminho normalizado atende ao SLO após melhorias de índice ou hardware por dois trimestres consecutivos.

Como isso se relaciona com data warehouses?

Data warehouses desnormalizam por design. A desnormalização OLTP ainda precisa de invariantes porque as aplicações escrevem as mesmas linhas das quais as transações dependem.

Relacionados

Noções Básicas de Normalização - design normalizado de linha de base
Desnormalização Intencional - padrões de implementação
Visualizações Materializadas - mecânica de atualização
Melhores Práticas de Modelagem de Dados - lista de revisão de modelagem

Versões da Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x e PostGIS 3.5+.

Melhores Práticas de Desnormalização

Buscar na documentação

Melhores Práticas de Desnormalização