Respostas:
Você deve ir tão longe quanto deveria, e não mais longe. Claro. ~ O problema pode ser que isso é um pouco de arte, e é por isso que não é uma ciência pura.
Nosso principal produto é um sistema de análise e relatório e, nesse sentido, temos alguns registros detalhados. Inicialmente, ele foi projetado com muitas junções em um ID comum para alguns dos registros filhos, mas descobrimos que, se desnormalizássemos alguns campos, podíamos cortar MUITAS junções e tirar muitas dores de cabeça de desempenho.
Mas só sabíamos disso porque: 1) criamos um design "normalizado", 2) começamos a usá-lo, 3) criamos o perfil do desempenho real após centenas de milhões de linhas em dezenas de tabelas.
A história final é que, até que apresentássemos o perfil , não sabíamos ao certo o que iria funcionar 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.
in ('forgiven','pardoned');): p
A normalização é uma meta somente quando ela suporta seu modelo de dados o suficiente para justificá-lo. Ele deve ser um guia para permitir crescimento, gerenciamento e manutenção. Lembre-se de que o livro sobre normalização, nem seu escritor, criará ou manterá seu banco de dados ou seu aplicativo.
Uma boa leitura sobre o assunto "muita normalização" está aqui.
E sim, pode haver impactos no desempenho com muita normalização. Isso ocorreria em uma travessia mais profunda da tabela para selecionar itens 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 de status de "Bom" para "BOM" ou algo parecido) ou em manutenção.
Recomendo a leitura do apêndice a seguir, encontrado em algumas livros mais recentes Chris Date :
Dois elogios para a normalização
A normalização está longe de ser uma panacéia, como podemos ver facilmente considerando quais são seus objetivos e quão bem ele 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 projeto totalmente normalizado é fortemente contra-indicado ...
Eu acho que é igualmente importante observar as desnormalizações adicionadas explícitas, 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ê aplicar isso, esses campos são 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 você deve criar um perfil das consultas criadas sobre o seu modelo, especialmente as executadas com frequência.
Minha própria experiência: os atributos que precisaram de duas junções para alcançar (ou seja, três tabelas unidas) serão principalmente prejudiciais ao desempenho. E para piorar as coisas, é usado em transações on-line. Como eu desnormalizo o atributo, ele precisa apenas de uma associação e solicitou ao programador que ajuste o aplicativo para a consulta e atualize o atributo. Agora funciona muito melhor ...
Em outras palavras, você deve equilibrar normalização com desempenho.