Até onde você deve ir com a normalização?

Você deve ir até onde deve, e não mais. É claro. ~ O problema pode ser que isso é um pouco de arte, e é por isso que isso não é uma ciência pura.

Nosso principal produto é um sistema de análise e relatórios e, nesse sentido, temos alguns registros detalhados. Inicialmente, o projetamos com muitas junções em um ID comum para alguns dos registros filhos, mas descobrimos que, se desnormalizássemos alguns campos, poderíamos cortar MUITAS junções e eliminar muitos problemas de desempenho.

Mas só sabíamos disso porque 1) criamos um design "normalizado", 2) começamos a usá-lo, 3) traçamos o perfil do desempenho real após centenas de milhões de linhas em dezenas de tabelas.

A história final é que, até traçarmos o perfil , não poderíamos saber ao certo o que funcionaria para nós. Gostamos da ideia de normalizar para que pudéssemos atualizar com mais facilidade, mas no final o desempenho real foi o fator decisivo. Esse é o meu conselho para você: perfil, perfil, perfil.

A normalização é uma meta apenas quando suporta seu modelo de dados bem o suficiente para justificá-la. Destina-se a ser um guia para permitir o crescimento, gerenciamento e manutenção. Lembre-se de que nem o livro sobre normalização, nem seu autor irão construir ou manter seu banco de dados ou sua aplicação.

Uma boa leitura sobre o assunto "normalização demais" está aqui.

E, sim, pode haver um impacto no desempenho devido ao excesso de normalização. Isso seria uma passagem de tabela mais profunda para pegar coisas como tabelas de indicadores de status quando elas foram puxadas para uma tabela separada. Alguns dirão que isso geralmente é negado na velocidade de atualização (alterando o texto do status de "Bom" para "BOM" ou algo parecido) ou na capacidade de manutenção.

Recomendo a leitura do seguinte apêndice encontrado em alguns dos livros mais recentes de Chris Date :

Dois vivas para a normalização

A normalização está longe de ser uma panacéia, como podemos ver facilmente ao considerar quais são seus objetivos e quão bem ela se compara a eles...

Devo deixar claro que não quero que meus comentários nesta seção sejam vistos como qualquer tipo de ataque. Acredito firmemente que qualquer coisa menos do que um design totalmente normalizado é fortemente contra-indicado...

Eu acho que é igualmente importante olhar para as desnormalizações adicionadas explícitas, sejam valores agregados adicionados ou alguns campos de uma tabela mestre copiada para uma cópia detalhada.

O argumento é principalmente algum argumento de desempenho.

Se você fizer isso, certifique-se de que esses campos sejam atualizados por gatilhos e cabe ao banco de dados mantê-los consistentes.

Eu concordo totalmente com @jcolebrand. Ao projetar o modelo para seu aplicativo, você deve normalizar tudo o que puder. Mas então você deve criar o perfil das consultas construídas sobre seu modelo, especialmente aquelas executadas com frequência.

Minha própria experiência: atributos que levaram duas junções para serem alcançados (isso significa três tabelas unidas) serão principalmente um porco de desempenho. E para piorar, é usado em transações online. Eu desnormalizei o atributo, então ele só precisa de um join e pediu ao programador para ajustar seu aplicativo para a consulta e atualizar o atributo. Agora funciona muito melhor...

Em outras palavras, você deve equilibrar a normalização com o desempenho.